iOS開發>學無止境 - 使用MVC模式幫ViewController瘦身

標籤：

隨著程式邏輯複雜度的提高，你是否也發現了App中一些ViewController的程式碼數急劇增多，達到了2，3千行，甚至更多。這時如果想再添加一點功能或者修改現有邏輯變得讓人無比頭疼。如果你遇到了這類問題，那是時候停下來了，思考一下如何更好地組織代碼，給VC瘦身。本文將會闡述如何結合MVC的思想幫你的VC瘦身同時提高複用和可擴充性。

 

一、開發中常見的現象和缺點

 

iOS中最常見的一種設計模式就是MVC，但在實際開發過程中，我們因為這樣、那樣的原因讓單純的ViewController變成了集Model，Controller以及View的一個大集合，這樣勢必就會導致VC的代碼容量呈幾何增長。這樣的代碼會存在以下幾個問題：

 

1、不利於後續維護

 

代碼在一個公司的存活時間通常遠長於你在公司的時間，你是否也在接手現有項目以後邊看代碼邊在心裡默念“a piece of shit”，我想沒有一個人希望之後接手你代碼的人有一天看你代碼的時候也在心裡默念著同樣的話。作為一個有追求的程式員，或者說為了不被以後的同事罵，我們必須要為自己的代碼負責，避免動輒就是幾千行的一個源檔案。你自己寫的都不願因看，更何況後續接手的人呢。

 

如果項目進度很趕，當時沒有時間對代碼進行合理的拆分和重構，後續也一定要抽出時間來填一下自己挖的坑。你可能會說，公司一直都很忙沒有時間留給你去重構。我只能說要不就是你自己不會安排時間，要不就是這個公司只把你當代碼搬運工。站在長遠發展的角度上，要麼改變自己，要麼炒了老闆。

 

2、不利於支撐UI的變動

 

試想如果有一天你們的App的UI風格需要改變，大量的View需要改變，在一個幾千行的VC中刪刪改改是什麼感受。可能因為改動UI的時候一個不留神錯改了Model或者Controller的東西，導致程式都不能正常運行。而且改動的範圍不能控制在一個較小的範圍，測試迴歸起來的工作量也是很大的。

 

3、不利於複用

 

如果你的App一開始只支援iPhone版本，所有的一切都那麼自然，程式也啟動並執行很好。突然有一天老闆告訴你說公司業務發展的不錯，為了擴大市場需要退出iPad版，這個時候如果僅僅只是iPhone版本的放大版，那麼你需要做的可能就是添加一些view的自適應就好了。但現實並不總是理想，如果iPad版的需要重新設計，按鈕的位置都變動了(參考上面的第二點)，這個時候難道需要把所有的代碼都改一遍？這尼瑪工作量也太巨大了吧。

 

通常iPhone版本和iPad版本不管UI怎麼變，商務邏輯只是基本相同的，那麼如果當初我們的代碼層級比較清晰，是不是Controller和Model層就可以完美的複用呢，針對不同的版本換一套View即可，這個是不是方便多了，自己感受一下。

 

 

二、如何解決這些問題

 

第一部分說了這麼多終於點題了，如何使用MVC模式更好的給VC瘦身，提高複用性和可維護性呢？我畫了下面一個圖：

解釋一下上面這幅圖，一個完整的模組被分為了三個相對獨立的部分，分別是Model，View，Controller，對應到我們App中的依次為繼承自NSObject的資料中心，承載UI展示和事件響應的View以及我們最最常用的UIViewController。

 

其中VC持有View和Model部分，View通過代理或者Target-Action的方式把使用者的操作傳遞給VC，VC負責根據不同的使用者行為做出不同響應。如果需要載入或重新整理資料則直接調用Model暴露的介面，如果資料可以同步拿到，則直接使用擷取到的資料重新整理View。如果資料需要通過網路請求等其他非同步方式擷取，VC則通過監聽Model發出的資料更新(成功或失敗)通知，在收到通知時根據成功或者失敗對View進行相應的重新整理操作。可以看出來整個過程中View和Model是沒有直接互動的，所有的操作都是通過VC進行協調的。

 

進過MVC分層的好處：

 

1、VC代碼量驟降，易於維護

 

可以看到拆分後VC中就僅剩下事件的響應操作了，所有顯示相關的東西都被單獨抽取出來，所有的網路請求以及資料緩衝都被提取到出去了。VC中的代碼會大幅度減少，在我們項目中的實踐結果為：拆分前一個VC的程式碼數為2600行，拆分後VC的程式碼數僅剩不到600行。

 

2、複用性提高

 

拆分後如果App需要對UI展示進行大改，那麼你的改動基本上都會停留在View模組中，你可以選擇在現有的基礎上改，也可以選擇從寫一個。只要業務不變的話，Model和VC模組完全不需要修改。這樣改動的範圍較小，對開發與測試都比較友好。

 

拆分後如果App需要支援iPad版本，那麼你需要做的就只是重寫一個View然後放進去就好了，Model和VC模組同樣基本上不要做任何修改，想想是不是還有點兒小激動呢。

 

 

三、總結

 

使用MVC模式可以達到幫VC瘦身，可以到到提高複用性和可維護性的效果，同時也會讓原本一個整體的業務代碼，分散到各個不同的地方。實際使用中我們需要具體問題具體分析，如果一個VC中的東西本身就很簡單，那麼完全可以放在一起，因為即使全部放在一起也就幾百行代碼。例如App中常見的Copyright介面，本身就是載入一個html就搞定了，就完全沒必要搞得那麼複雜；如果一個VC已經很複雜，代碼動輒幾千行了，那麼就需要拆分，達到更好的複用以及方便維護的目的。

 

寫了幾年代碼了，見過所有東西都往一個源檔案裡面塞的，也見過一個本就很簡單的東西被設計模式搞的四分五裂的，不要為了用設計模式而用設計模式。把握好度很重要，能用子彈解決的問題就不要動大炮。

 

代碼重構應該是一個持久的過程，在開發的過程中就時不時的對現有不合理的地方進行重構，而不是等待問題已經很多了才想起重構來。千裡之行始於足下，千裡之堤潰於蟻穴。

 

原文連結：smileEvday

來源連結：http://www.cnblogs.com/smileEvday/p/iOS_MVC.html

 

iOS開發>學無止境 - 使用MVC模式幫ViewController瘦身