从这幅图可以看到，我们可以看到在MVC里，View是可以直接访问Model的！从而，View里会包含Model信息，不可避免的还要包括一些业务逻辑。
在MVC模型里，更关注的Model的不变，而同时有多个对Model的不同显示，及View。
所以，在MVC模型里，Model不依赖于View，但是View是依赖于Model的。不仅如此，因为有一些业务逻辑在View里实现了，导致要更改View也是比较困难的，至少那些业务逻辑是无法重用的。
Visual Studio等快速开发工具，让我们很难把View和Controller分开，我们总是直接在View的事件响应函数里完成了Controller的代码。而在ASP.NET和XAML里，使用了一种叫做Code-Behind的技术，可以把View和Controller进行分离。这样，View就可以完全由UI设计工程师来完成，而Controller由程序员来完成，两者可以直接合成不需要像现在一样再由程序员做很多的工作。
把Controller和View混在一起，有什么问题？
１.难以测试。
必须手动点击，使用各种自动化的测试工具。
２.代码难以重用。
UI是很难重用，因为要求总是不同。所以，导致重复的代码四处都是，维护麻烦。
MVP
View ：是指显示数据并且和用户交互的层。在安卓中，它们可以是一个Activity，一个Fragment，一个android.view.View或者是一个Dialog。
Model ：是数据源层。比如数据库接口或者远程服务器的api。
Presenter：是从Model中获取数据并提供给View的层，Presenter还负责处理后台任务
MVP是一个将后台任务和activities/views/fragment分离的方法，让它们独立于绝大多数跟生命周期相关的事件。这样应用就会变得更简单，整个应用的稳定性提高10倍以上，代码也变得更短，可维护性增强，程序员也不会过劳死了~~
一个暴露接口,一个实现接口,流水式的设计,单向
在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很大的不同之处。
1. MVP 就是通过Presenter(主持)把View和Modle分开（最好用接口分开)
方便管理 example:
AppHolder appHolder = new AppHolder();
view.add(appHolder.views);//加载view
appHolder.bind(list);//加载数据
MVVM
他是真正和实现view 和model分离,修改model 不影响view
xml文件里根节点是<layout...
<data>
...
</data>
需要监听
绑定数据（按文档）