最近在学习设计模式，自己做了个小demo。下面记录下

实际iOS开发中的MVC模式中，controller模块跟view模块紧密耦合，很容易形成胖controller，可单元测试弱。但能快速开发。MVP模式把传统的iOS开发的MVC模式下比较完美的展示。使用Presenter模块当做controller。把传统的UIViewController跟UIView当作view模块，绑定view跟model。这个设计模式增强了代码的单元测试。MVP跟MVC都存在一个问题，很容易形成胖的viewController跟胖的presenter。而MVVM 中使用的是响应式viweModel 是个中介者。它做数据处理，双向绑定技术，当Model变化时，View-Model会自动更新，View也会自动变化。很好做到数据的一致性，不用担心，在模块的这一块数据是这个值，在另一块就是另一个值了。所以 MVVM模式有些时候又被称作：model-view-binder模式。 MVVM的缺点是难以调式。数据绑定使得一个位置的 Bug 被快速传递到别的位置，要定位原始出问题的地方就变得不那么容易了。 

MVC

以上所述，似乎Cocoa MVC 看起来是一个相当差的架构方案。我们来重新评估一下文章开头我们提出的MVC一系列的特征:

任务均摊--View和Model确实是分开的，但是View和Controller却是紧密耦合的

可测试性--由于糟糕的分散性，只能对Model进行测试

易用性--与其他几种模式相比最小的代码量。熟悉的人很多，因而即使对于经验不那么丰富的开发者来讲维护起来也较为容易。

如果你不想在架构选择上投入更多精力，那么Cocoa MVC无疑是最好的方案，而且你会发现一些其他维护成本较高的模式对于你所开发的小的应用是一个致命的打击。

“就开发速度而言，Cocoa MVC是最好的架构选择方案。”

总结

vc中子类view跟model，

MVP

MVP是第一个如何协调整合三个实际上分离的层次的架构模式，既然我们不希望View涉及到Model，那么在显示的View Controller（其实就是View）中处理这种协调的逻辑就是不正确的，因此我们需要在其他地方来做这些事情。例如，我们可以做基于整个App范围内的路由服务，由它来负责执行协调任务，以及View到View的展示。这个出现并且必须处理的问题不仅仅是在MVP模式中，同时也存在于以下集中方案中。

我们来看下MVP模式下的三个特性的分析：

任务均摊--我们将最主要的任务划分到Presenter和Model，而View的功能较少（虽然上述例子中Model的任务也并不多）。

可测试性--非常好，由于一个功能简单的View层，所以测试大多数业务逻辑也变得简单

易用性--在我们上边不切实际的简单的例子中，代码量是MVC模式的2倍，但同时MVP的概念却非常清晰

“iOS 中的MVP意味着可测试性强、代码量大。”

总结

在viewController中只有view属于它的子类，model不属于。model放在presenter中。

Presenter把model跟view绑定，

MVVM

Model层是少不了的了，我们得有东西充当DTO(数据传输对象)，当然，用字典也是可以的，编程么，要灵活一些。

ViewModel层，就是View和Model层的粘合剂，他是一个放置用户输入验证逻辑，视图显示逻辑，发起网络请求和其他各种各样的代码的极好的地方。说白了，就是把原来* ViewController层的业务逻辑和页面逻辑等剥离出来放到ViewModel层。

View层，就是ViewController层，他的任务就是从ViewModel层获取数据，然后显示。 上面对MVVM就先简单的这么一说，好好的理解并应用的话，还得实战。

总结

把处理数据逻辑放到viewmodel里，viewController只需要接收返回的数据。

VC上绑定一个viewModel ,viewModel处理完数据后通知view刷新。VC的属性有viewModel跟view, viewModel属性有model。viewModel获得model数据，通过viewModel接收事件。viewModel层是处理model数据后返回最后的结果给view。