(這幾天有部分同學反映序章內容概括得不太容易理解。因此，我從別處扒了一張汽車裝配的示意圖補充在文章後半部分–五、開發中的裝配流水線，通過這種比較形象的方式，整體描述下我們這種設計模式的工作方式)
前言：
開篇之前，先貼上以該設計模式為基礎的iOSAPP的App Store地址:https://appsto.re/cn/neiscb.i
這個專案通過我所要講的設計模式，三個人在同時需要忙於其他專案維護的情況下，從開工到上架，前前後後加起來用了一個月的時間。因此，在保證專案質量的前提下，敏捷開發以及如何保持多人協同開發，後期新需求程式碼迭代，是這設計模式所解決的問題。
促成自己想寫下這個最容易被打臉的文章有兩個原因，一方面是因為想把我在這個專案的經驗總結出來與大家分享，並希望得到各位大牛的建議（因為就我個人而言，我理解的這個MVVM模式並不是教科書式的）；另一方面，也是看到網路上很多文章並沒有具體結合到實際專案講解MVVM這個設計模式，很多讓人看了雲裡霧裡，不明其究。
廢話不多講，接下來正式開始，這個設計模式，我打算以6章節的文章分享出來，他們包括：
1.序章；
2.model–如何高效利用資料層；
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–如何高效利用資料層 。