MVC和MVP到底有什么区别呢？

MVC和MVP到底有什么区别呢？

从这幅图可以看到，我们可以看到在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是如何解决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很大的不同之处。

参考：

• MSDN的MVP介绍
• Presenter First
• The Humble Dialog