(这几天有部分同学反映序章内容概括得不太容易理解。因此，我从别处扒了一张汽车装配的示意图补充在文章后半部分–五、开发中的装配流水线，通过这种比较形象的方式，整体描述下我们这种设计模式的工作方式)

前言：

开篇之前，先贴上以该设计模式为基础的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–如何高效利用数据层 。