MVC 模式
Model
是对应用状态和业务功能的封装
View
实现可视化UI的呈现，捕捉最终用户的交互操作（键盘、鼠标）
Controller
View捕捉到用户交互操作后，会直接转发给Controller，后者完成相应的UI逻辑
如果需要设计业务功能的调用，Controller会直接调用Model
备注：1.Model接受Controller的请求，执行相应的业务功能，并在状态改变时通知View，
2.Model维护着整个应用的状态（数据和行为），并实现了所有的业务逻辑，可以看作为一个领域模型。
3.Controller在View处理结束之后，会根据需要控制原View，或者创建新View来对用户交互操作进行响应。
MVC模式的混乱之处在意View和Model可以绕过Controller，进行直接交互
在MVC中，View会直接从Model中读取数据而不是通过Controller，这样View是可以直接访问Model的，从而，View里会包含Model信息，不可避免的还要包含一些业务逻辑。在MVC模型里，更关注的Model的不变，而同时有多个对Model的不同显示、VIew。所以在MVC模型里，Model不依赖View，但是View依赖于Model。不仅如此，因为有一些业务逻辑在View里实现了，导致要更改View也是比较困难的，至少那些业务逻辑无法重用。
MVP如何解决MVC的问题
在MVP中，Presenter完全把Model和View进行了分离，主要的程序逻辑在Presenter里实现。而且，Presenter与具体的View是没有直接关联的，而是通过定义好的接口进行交互，从而使得在变更View时候可以保持Presenter的不变，即重用！不仅如此，我们还可以编写测试用的View，模拟用户的各种操作，从而实现对Presenter的测试——而不需要使用自动化的测试工具。我们甚至可以在Model和View都没有完成的时候，就可以通过编写Mock Object（即实现了Model和View的接口，但没有具体的内容的）来测试Presenter的逻辑。在MVP中，应该程序的逻辑主要在Present来实现，其中的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了，那么视图很有可能也需要变更。