搜尋

隨機推薦

22 六月 2011

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

mvc.png

由於採用了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改變了,那麼調用我寫的函數是不是格式 不變?如果你寫的函數,一會兒增加個參數,一會減少個參數,那麼所有調用的地方都會跟著變化修改。

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

廣告

无觅相关文章插件,快速提升流量

Please publish modules in offcanvas position.