MVC设计模式
是一种使用 MVC（Model View Controller 模型-视图-控制器）设计创建 Web 应用程序的模式：Model（模型）表示应用程序核心（比如数据库记录列表）、View（视图）显示数据（数据库记录）、Controller（控制器）处理输入（写入数据库记录）是一种设计模式根据项目具体需求确定是否使用。
用户在View上触发通过Controller处理业务用于更新数据，数据更新后发送消息用于改变显示或Controller直接反馈用户。在MVC基础上为了更好的复用（高内聚低耦合）降低View与Model的耦合，从而进行改进：
看起来是不是很像MVP?
同样的切断了View与Model的联系，Controller/Presenter负责逻辑的处理，Model提供数据，View负责显示。在MVP里，Presenter完全把Model和View进行了分离，主要的程序逻辑在Presenter里实现。而且，Presenter与具 体的View是没有直接关联的，而是通过定义好的接口进行交互，从而使得在变更View时候可以保持Presenter的不变，即重用。这段描述摘自
MVP的优点：
- 模型与视图完全分离，我们可以修改视图而不影响模型；
- 可以更高效地使用模型，因为所有的交互都发生在一个地方——Presenter内部；
- 我们可以将一个Presenter用于多个视图，而不需要改变Presenter的逻辑。这个特性非常的有用，因为视图的变化总是比模型的变化频繁；
- 如果我们把逻辑放在Presenter中，那么我们就可以脱离用户接口来测试这些逻辑（单元测试）。
改进后降低了View与Controller的耦合，所有的消息处理交给Controller。这是种非常理想的状态，明显优于原始的MVC。但在实际开发中所有View与Model交互通过Controller后会造成Controller上逻辑过于复杂代码臃肿。
在此基础上我们继续优化参考objc.io：
- 将TableView的DataSource分离出来
- 将网络请求和Model转换分离到另外一个类中
- 将拼装复用的控件拆分到另一个类中
如何得到的上述结论？
很多设计模式都遵循共同的特点“可维护”，对于View及Model来说，如果抽象的好、封装的好，就可以随意哪类复用，也便于维护。Model是业务数据如果可以在同一个项目内也可以复用。而Controller中包含网络请求、数据处理、以及交互逻辑无法复用且臃肿。所以在MVC的基础上我们可以针对“肿块”“切开”重组。
- 针对网络请求数据处理：
唐巧曾介绍过将每个网络请求抽象成单独的类[把每一个网络请求封装成对象其实是使用了设计模式中的 Command 模式：将请求封装成对象，以便使用不同的请求、日志、队列等来参数化其他对象。命令模式也支持撤销操作]
优点：
* 方便更换第三方依赖库
* 在积累中处理公共逻辑、缓存逻辑
* 方便对象持久化
* 简化Controller逻辑
- 将拼装控件抽象到专门的类中
可复用的控件封装、
用一个静态类帮助拼装、
我们在拆分Controller的过程中对于Controller与View的传值过程拿出来抽象，便成了ViewModel，数据库结构往往是不能直接跟界面控件一一对应上的，所以，需要再定义一个数据对象专门对应view上的控件。而ViewModel的职责就是把model对象封装成可以显示和接受输入的界面数据对象。
看到这里是不是已经像MVVM模式了？我的理解是实际上Model-ViewModel-ViewController-View其实就是MVC基础上将臃肿的Controller拆分开来。 在实际应用中无需拘泥于形式一定是MVC模式或者MVVM模式、MVP模式合理的搭配使用。
