要不要 MVC ，本身就是選擇題

由於採用了Web開發框架來開發項目，所以我首次在真正的項目中採用MVC的開發模式。隨著項目的不斷深入，我也在不斷反思，MVC設計模式到底給項目帶來了什麼？成倍的開發時間？複雜無比的目錄結構？鋪天蓋地的文件數量？聽起來都很難聽對嗎，但是確實如此。那麼MVC所許諾的那些好處呢？清晰的代碼結構，易於維護，易於擴展？真有嗎？

當然，我不是在批判MVC，只是覺得，在使用MVC過程中，還是需要投入更深入的思考，到底怎樣才能用好這個設計模式。MVC給我的感覺是，要求使用其的開發者有更高的覺悟，來正確選擇存放一段代碼的地方。從而實現解耦合，代碼復用，和易於維護。為什麼說使用MVC會有成倍的開發時間，主要就是因為在開發中，我們需要更多的時間去思考，這些代碼放在哪裡更合理一些。在MVC框架下代碼被切割成一個又一個的小文件，分散在複雜的目錄樹中，那麼到底怎樣選擇把代碼寫在哪裡呢？這道選擇題，並非有看起來那麼容易。就我個人感受而言，更多的時候，無論將代碼放在哪裡都可以正確實現你的邏輯，MVC不是什麼神兵利器，並不能通過其模式本身的約束，將開發者導入到一個正確的軌道上，反而會因為開發者本身錯誤的選擇而讓MVC自己變得一團糟。所以說，當一個團隊確定要在一個項目中引入MVC時候，應該思考一下，每個團隊成員是不是真的都有能力駕馭，如果沒有對應的能力話，是不是要考慮前期對項目成員進行一定的培訓。

可能我說得話很裝逼，但是我絕對不敢以一個專家的身份站到這裡來說話，我只是一個初學者，我要把我的學習感受說出來。現在回歸到MVC上，Controller 給我的印象是一個協調者的形象，它知道誰能幹什麼，然後分配任務，構造哪個對象，初始化哪個視圖，是Controller應該決定的事情。Model呢， 應該是一個實幹家的形象，負責所有骯髒而又細緻的事情，所以我在編碼實踐中，將所有的業務邏輯都塞進Model裡面，對Controller，提供一個簡 單接口，對Views，輸出純數據。View則是一個消費者的形象，給其的數據都是純粹的，直接顯示即可以。以上是我對MVC這道選擇題給出的一個答案，當然我不是很確定這樣做很對。

我在項目中就看到過這樣的代碼，將Model做成了一個工具箱，實際上是一個有各種方法的對象，每個方法看起來也提供了簡單的調用接口，實際跟 Controller配合時候呢，由Controller來操縱功能，安排各個方法被調用的順序。這等於是由Controller來執行業務邏輯，但是卻 又對其封裝了每個步驟的細節。而我個人傾向於連業務邏輯也對Controller封裝。這兩種選擇各有優劣，而實際上從短期也難看出來誰更剩一籌。甚至， 等項目上線後，最終也沒法發現哪個做法更優一點。

所以說，MVC真 的就是一個選擇題。你有多重選擇來實現同一個目的。我列舉的例子只是九牛一毛，在實際項目開發中，還面臨著更多的選擇問題。我想，到底怎樣交出自己的答 案，還是應該在實踐過程中不斷積累，不斷優化。我們只要把握好一些原則，就可以讓自己不要偏離航向太遠。第一，可維護性，代碼邏輯一目瞭然應該是寫代碼時 候的第一追求，因為看別人的代碼是非常痛苦的，甚至最後回頭來看自己寫過的代碼可能都會很痛苦，保持代碼一目瞭然才是最重要的，給別人，給自己節省下時 間。第二，可復用性，寫內聚度高的代碼，減少依賴，判定很簡單，我寫的這個代碼，拷貝到別的項目裡，是不是直接就能用，時刻問自己這個問題，就能保持代碼 的高內聚度。第三，封裝變化，這個原則總體來說很難把握住，我自己的體會就是儘可能提供一個強大的接口，如果XXX改變了，那麼調用我寫的函數是不是格式 不變？如果你寫的函數，一會兒增加個參數，一會減少個參數，那麼所有調用的地方都會跟著變化修改。

就到此為止了，一些愚見，請大家指正。