如何給uiviewcontroller**
ios中最常見的一種設計模式就是mvc，但在實際開發過程中，我們因為這樣、那樣的原因讓單純的viewcontroller變成了集model，controller以及view的乙個大集合，這樣勢必就會導致vc的**容量呈幾何增長。這樣的**會存在以下幾個問題：
**在乙個公司的存活時間通常遠長於你在公司的時間，你是否也在接手現有專案以後邊看**邊在心裡默念「a piece of ****」，我想沒有乙個人希望之後接手你**的人有一天看你**的時候也在心裡默念著同樣的話。作為乙個有追求的程式設計師，或者說為了不被以後的同事罵，我們必須要為自己的**負責，避免動輒就是幾千行的乙個原始檔。你自己寫的都不願因看，更何況後續接手的人呢。
如果專案進度很趕，當時沒有時間對**進行合理的拆分和重構，後續也一定要抽出時間來填一下自己挖的坑。你可能會說，公司一直都很忙沒有時間留給你去重構。我只能說要不就是你自己不會安排時間，要不就是這個公司只把你當**搬運工。站在長遠發展的角度上，要麼改變自己，要麼炒了老闆。
通常iphone版本和ipad版本不管ui怎麼變，業務邏輯只是基本相同的，那麼如果當初我們的**層級比較清晰，是不是controller和model層就可以完美的復用呢，針對不同的版本換一套view即可，這個是不是方便多了，自己感受一下。
第一部分說了這麼多終於點題了，如何使用mvc模式更好的給vc**，提高復用性和可維護性呢？我畫了下面乙個圖：
其中vc持有view和model部分，view通過**或者target-action的方式把使用者的操作傳遞給vc，vc負責根據不同的使用者行為做出不同響應。如果需要載入或重新整理資料則直接呼叫model暴露的介面，如果資料可以同步拿到，則直接使用獲取到的資料重新整理view。如果資料需要通過網路請求等其他非同步的方式獲取，vc則通過監聽model發出的資料更新(成功或失敗)通知，在收到通知時根據成功或者失敗對view進行相應的重新整理操作。可以看出來整個過程中view和model是沒有直接互動的，所有的操作都是通過vc進行協調的。
進過mvc分層的好處：
可以看到拆分後vc中就僅剩下事件的響應操作了，所有顯示相關的東西都被單獨抽取出來，所有的網路請求以及資料快取都被提取到出去了。vc中的**會大幅度減少，在我們專案中的實踐結果為：拆分前乙個vc的**行數為2600行，拆分後vc的**行數僅剩不到600行。
寫了幾年**了，見過所有東西都往乙個原始檔裡面塞的，也見過乙個本就很簡單的東西被設計模式搞的四分五裂的，不要為了用設計模式而用設計模式。把握好度很重要，能用子彈解決的問題就不要動大炮。
**重構應該是乙個持久的過程，在開發的過程中就時不時的對現有不合理的地方進行重構，而不是等待問題已經很多了才想起重構來。千里之行始於足下，千里之堤潰於蟻穴。
**：
iOS開發中的MVC
m model，個人理解為業務邏輯，也就是你的程式處理了一些什麼樣的業務，一般是一系列的api供controller呼叫 v view，檢視，也就是你的程式外觀 ui，你所能看到，觸控到的，程式的展現 c controller，控制器，個人理解為程式邏輯，作為m和v溝通的橋梁，在ios開發中經常被放...
iOS中的高效開發
工欲善其事必先利其器，合理的利用工具，提公升開發效率，不僅僅幫助我們節省時間，關鍵是能幫我們從一些重複 低效的工作中抽離出來，專注於有挑戰，有深度的問題，不斷提公升自己。這裡總結一些我在日常開發中提公升開發效率的一些技巧，如果您有更好的提公升效率的方法也請不吝賜教。自定義xopen快捷指令碼，在終端...
iOS開發基礎 MVC
mvc模式我們談得夠多了，但總有一些爭議，比如rac說明文件裡關於mvc的描述是這樣的 來自reactivecocoa專案 史丹福大學的ios公開課第一課 來自斯坦福公開課 中文維基百科上mvc條目的配圖 來自中文維基百科 乍一看，以上都是三角形，都描述了model view controller三...