(這幾天有部分同學反映序章內容概括得不太容易理解。因此，我從別處扒了一張汽車裝配的示意圖補充在文章后半部分--五、開發中的裝配流水線，通過這種比較形象的方式，整體描述下我們這種設計模式的工作方式)
前言：
開篇之前，先貼上以該設計模式為基礎的iOSAPP的App Store地址:https://appsto.re/cn/neiscb.i
這個項目通過我所要講的設計模式，三個人在同時需要忙于其他項目維護的情況下，從開工到上架，前前后后加起來用了一個月的時間。因此，在保證項目質量的前提下，敏捷開發以及如何保持多人協同開發，后期新需求代碼迭代，是這設計模式所解決的問題。
促成自己想寫下這個最容易被打臉的文章有兩個原因，一方面是因為想把我在這個項目的經驗總結出來與大家分享，并希望得到各位大牛的建議（因為就我個人而言，我理解的這個MVVM模式并不是教科書式的）；另一方面，也是看到網絡上很多文章并沒有具體結合到實際項目講解MVVM這個設計模式，很多讓人看了云里霧里，不明其究。
廢話不多講，接下來正式開始，這個設計模式，我打算以6章節的文章分享出來，他們包括：
1.序章；
3.view--業務與界面結合的模塊開發；
4.controller--標準的流水組裝線；
5.業務的分析與分解;
6.研發人員如何從繁多的項目中解放出來與輕負荷協同開發。
序章：
一、為何我會將這種模式叫做積木模式
通過這種模式做項目，就像搭積木（功能模塊）一樣，將各種規則的形狀搭建成如房屋、城堡（項目）等；如果哪塊積木搭建得不正確（需求迭代）或者積木損壞（BUG），只需要將其抽出替換即可，并不會影響到其他積木搭建的地方。并且，如果整個搭建的物件，自己并不滿意的話，完全可以將其推翻了快速重新搭建。
二、mvvm、mvp等設計模式即從mvc提煉出一個核心層衍生而來
首先，放上一個mvc的展示圖：
圖片中展示的內容，大家應該一看就明白，這里重點想表達的是無論是mvvm、mvp還是其他從mvc衍生而來的設計模式，核心內容都是將controller中繁雜的業務代碼提煉到其他新建的層中或新的業務代碼中。如mvvm是將業務代碼放到viewmodel層，而mvp則是直接將相應的業務代碼叫給相應的View進行回調響應。而我這里所講的設計模式，同樣是分離controller中繁雜的業務代碼，一部分（模塊內業務與對外響應業務）分給view，一部分(第三方的數據互通與數據重組)分給model。但本質上，仍然是mvc的設計模式。
三、積木模式的項目開發思路
廢話不說，直接上圖(如有不明白的地方，歡迎留言)：
四、積木的設計模式
廢話不說，同樣直接上圖(如有不明白的地方，歡迎留言)：
五、開發中的裝配流水線
如下圖，整條流水線和項目設計圖（需要的模塊和接口）由項目設計者定制；
淺橙色一塊則是開發人員在前期開發項目需要制作的各種模塊；
具體的某條流水線（發動機裝配）：由開發人員在contorller將各個View模塊組裝在一起，之間的接口通信，則是由相應的ViewModel將原始數據傳化成Model在View模塊內部或之間傳遞；
產品試驗（測試）：可以分為三處測試組件試驗（模塊單元測試），發動機試驗（controller功能界面測試），最后試驗（整體測試）。保證質量，責任具體到模塊；
流水線分工：成員間分工明確，統一協調，成員工作時長明確，代碼從做法上就整體有結構，不用定制過多的開發條條框框。
寫下這類文，既然講到了設計模式，必然涉及了開發中的每處細節和各個方面，肯定會有某處因經驗不足導致一些謬誤，所以，這里誠懇得希望各位看官們提供您們優秀的建議，惠及更多愿意學習的人。
自此，序章暫時結束，后面想到更多會補充上去，同時，也希望各位大牛多多指點，發此文章的本意就是希望能與更多的人開發者們交流一個更方便于我們開發者、更低成本于公司的設計模式。
接下來幾天時間會總結 model--如何高效利用數據層 。
