7.4 MVC vs MVP

　　MVC(Model_view_contraller)”模型_视图_控制器”。 MVC应用程序总是由这三个部分组成。Event(事件)导致Controller改变Model或View，或者同时改变两者。只要Controller改变了Models的数据或者属性，所有依赖的View都会自动更新。从右图可以看到，我们可以看到在MVC里，View是可以直接访问Model的！从而，View里会包含Model信息，不可避免的还要包括一些业务逻辑。

　　在MVC模型里，更关注的Model的不变，而同时有多个对Model的不同显示，及View。所以，在MVC模型里，Model不依赖于View，但是View是依赖于Model的。不仅如此，因为有一些业务逻辑在View里实现了，导致要更改View也是比较困难的，至少那些业务逻辑是无法重用的。

把Controller和View混在一起，有什么问题？

1. 难以测试：必须手动点击，使用各种自动化的测试工具。
2. 代码难以重用：UI是很难重用，因为要求总是不同。所以，导致重复的代码四处都是，维护麻烦。

MVP是如何解决MVC的问题的？

　　在MVP里，Presenter完全把Model和View进行了分离，主要的程序逻辑在 Presenter里实现。而且，Presenter与具体的View是没有直接关联的，而是通过定义好的接口进行交互，从而使得在变更View时候可以 保持Presenter的不变，即重用！不仅如此，我们还可以编写测试用的View，模拟用户的各种操作，从而实现对Presenter的测试--而不需要使用自动化的测试工具。我们甚至可以在Model和View都没有完成时候，就可以通过编写Mock Object（即实现了Model和View的接口，但没有具体的内容的）来测试Presenter的逻辑。

　　在MVP里，应用程序的逻辑主要在Presenter来实现，其中的View是很薄的一层。 因此就有人提出了Presenter First的设计模式，就是根据User Story来首先设计和开发Presenter。在这个过程中，View是很简单的，能够把信息显示清楚就可以了。在后面，根据需要再随便更改View， 而对Presenter没有任何的影响了。

　　如果要实现的UI比较复杂，而且相关的显示逻辑还跟Model有关系，就可以在View和 Presenter之间放置一个Adapter。由这个 Adapter来访问Model和View，避免两者之间的关联。而同时，因为Adapter实现了View的接口，从而可以保证与Presenter之 间接口的不变。这样就可以保证View和Presenter之间接口的简洁，又不失去UI的灵活性。

　　在MVP模式里，View只应该有简单的Set/Get的方法，用户用户输入和设置界面显示的内容，除此就不应该有更多的内容，绝不容许直接直接访问Model--这就是与MVC很大的不同之处。

MVP的优势

1. 模型与视图完全分离，我们可以修改视图而不影响模型
2. 可以更高效地使用模型，因为所以的交互都发生在一个地方——Presenter内部
3. 我们可以将一个Presener用于多个视图，而不需要改变Presenter的逻辑。这个特性非常的有用，因为视图的变化总是比模型的变化频繁。
4. 如果我们把逻辑放在Presenter中，那么我们就可以脱离用户接口来测试这些逻辑（单元测试）

MVP的问题

　　由于对视图的渲染放在了Presenter中，所以视图和Persenter的交互会过于频繁。

　　还有一点你需要明白，如果Presenter过多地渲染了视图，往往会使得它与特定的视图的 联系过于紧密。一旦视图需要变更，那么 Presenter也需要变更了。比如说，原本用来呈现Html的Presenter现在也需要用于呈现Pdf了，那么视图很有可能也需要变更。　　

第一阶段

　　使用传统的MVC，其中的View，对应的是各种Layout布局文件，但是这些布局文件中并不像Web端那样强大，能做的事情非常有限；Controller对应的是Activity，而Activity中却又具有操作UI的功能，我们在实际的项目中也会有很多UI操作在这一层，也做了很多View中应该做的事情，当然Controller中也包含Controller应该做的事情，比如各种事件的派发回调，而且在一层中我们会根据事件再去调用Model层操作数据，所以这种MVC的方式在实际项目中，Activity所在的Controller是非常重的，各层次之间的耦合情况也比较严重，不方便单元测试。

第二阶段

　　使用MVC的进化版——MVP，MVP中把Layout布局和Activity作为View层，增加了Presenter，Presenter层与Model层进行业务的交互，完成后再与View层交互（也就是Activity）进行回调来刷新UI。这样一来，所有业务逻辑的工作都交给了Presenter中进行，使得View层与Model层的耦合度降低，Activity中的工作也进行了简化。但是在实际项目中，随着逻辑的复杂度越来越大，Activity臃肿的缺点仍然体现出来了，因为Activity中还是充满了大量与View层无关的代码，比如各种事件的处理派发，就如MVC中的那样View层和Controller代码耦合在一起无法自拔。

第三阶段

针对第二阶段进行优化，为了把View再次简化，想到两种方式：

1. 用一个Presenter代理的方式，在PresenterProxy中处理各种事件机制，View中维护一个代理对象当然Presenter中同样实现了真实对象Presnter所实现的接口，这样，我们同样在View中通过代理对象调用真实对象的代码，结构图如左：

   

2. P增加一层专门用于处理各种的事件派发Controller层，Controller的作用仅仅是处理事件并根据事件通过维护的Presenter对象派发到对应的业务中，也就是说View层只有一个Controller的对象，View层不会主动去调用Presenter层，但是Controller层和Presenter都可能会回调到View层来刷新UI，所以层次结构就变成了如右上。

第四阶段：

　　MVVM，把Presenter改成ViewModel，它与View之间的交互可以使用Data Binding的方式双向进行，也就是说View和ViewModel任意一方的改变都会体现在另一方中，Google IO上提供的框架暂时还不成熟，只支持单向，所以暂时还没有在正式的项目中使用。

　　实质上MV*的思想都是一样的，解耦隔离视图（View）和模型（Model），在实际的应用中不需要给MVC、MVP和MVVM一个明确的界限，甚至可以把几者融合在一起。