展示模式架构比较MVP(SC)，MVP(PV)，PM，MVVM和MVC
介绍
本文将比较4重重要的展示模式架构，包括MVP(SC)，MVP(PV)，PM，MVVM和MVC。很多开发者围绕着这些模式间有什么不同及何时用哪种模式而感到困惑。本文将首先介绍背景之后解释不同的展示模式。接着我们将进一步讨论状态，逻辑和同步问题。最后我们将深入每种模式并总结它们之间的不同。
这里是对我的.NET朋友的小礼物，400页的FAQ电子书，包含各种.NET技术，例如Azure，WCF，WWF，Silverlight，WPF，SharePoint和其他。
全文是从http://martinfowler.com/eaaDev/uiArchs.htmlGUI架构的摘要。Mr. Martin flower的伟大工作。
Josh Smith和团队http://msdn.microsoft.com/en-us/magazine/dd419663.aspx，关于MVVM的伟大工作。
Mr. Mikhil kothari的博客http://msdn.microsoft.com/en-us/magazine/dd419663.aspx，关于MVVM的帅代码。
Mr. Oleg Zhukov解释了如何实现一个.NET的MVP框架，http://www.codeproject.com/KB/architecture/DotNetMVPFramework_Part1.aspx。
与用户界面相关的一个最大问题是大量杂乱的代码。这种混乱代码由于两个主要原因，首先是UI有复杂的逻辑来操作用户界面对象，，第二它还维护应用的状态。展示模式解决了围绕着如何删除UI的复杂性和是的UI更简洁和可管理的问题。下面是展示模式不同的变种和分类：
展示模式主要分为三类MVP(Model View Presenter)，MVC(Model View Controller)和最后的PM(Presenter Model)。MVP进一步分为监督控制器和被动视图。PM进一步被微软团队分成两个技术特定模式Sliverlight的MVVM和WPF的MVVM。
下面列出了UI相关的三大问题。
状态：状态/数据是UI最大担忧之一。状体意味着UI的当前数据展示。在Web术语里它可以是会话变量，而在Windows应用中它可以是简单地UI级数据。UI保持的状态越多，复杂性也越高。
逻辑：UI通常有UI逻辑，例如操作文本框，组合框或其他UI组件。在UI中，越多的这种逻辑存在，它就越复杂。
同步：UI通常要协调域/业务组件。UI还需要同步UI元素(文本框，组合框等)和业务对象间的数据。如果你的UI重复进行同步，那么UI的复杂性就大大增加。
展示设计模式帮举解决以上的UI问题。程序设计模式的基本逻辑是创建附加类，该类处理当前UI需要处理的复杂逻辑，数据和同步问题，使得UI转嫁责任，更简洁和简单。取决于这个类负责的职责，进一步定义为它为SC，PV，PM设计模式等等。换句话说，展示类的成熟度决定了它是哪种设计模式。
缩写全称
V视图或UI(View or UI)
P包含UI逻辑的展示器类(Presenter class which has the UI logic)
LUI逻辑(UI logic)
SUI的状态(State of the UI)
M业务组件或域对象(Bissiness components or domain objects)
SC监督控制器(Supervising controller)
PV被动视图(Passive view)
PV展示器模型(Presenter model)
我们使用以上缩写来简化展示设计模式的解释。
SC的基础：
状态存储在视图里。
展示器包含复杂的展示逻辑。简单的UI绑定逻辑通过使用绑定技术来完成，例如WIF绑定和Silverlight绑定。任何复杂性有展示器类处理。
展示器知道视图。
视图不知道知道展示器。
视图使用由WPF和Silverlight提供的绑定技术与模型链接。
PV的基础：
状态存储在视图里。
所有UI逻辑存储在展示器里。
视图与模型完全隔离。它还处理模型和视图见额外的同步任务。
展示器知道视图
视图不知道展示器。
你可以从这里知道更多关于MVP(PV)的知识，它还有一个样例代码，展示了MVP如何进入行动链的。
PM的基础：
状态储存在展示器里。
逻辑存储在展示器里。
展示器代编一个抽象的UI视图。
展示器不知道视图
视图知道展示器。
视图与模型完全隔离。
MVVM的基础：
展示器模型是基础。
状态储存在展示器里。
逻辑存储在展示器里。
展示器代表一个UI的抽像视图。
展示器不知道视图。
视图知道展示器。
视图与模型完全隔离。
使用WPF和Silverlight绑定。
MVC的基础：
没有展示器，有一个控制器。
请求首先到达控制器。
控制器绑定模型和视图。
逻辑存储在控制器里。
你可以从这里知道更多MVC的知识，它还有一个样例代码，展示了MVC如何处理行动链。
下面是对所有展示模式从状态，逻辑和同步方面总结的比较表格。
状态逻辑同步
Supervising Controller
PresenterXX
ViewX
ModelDatabinding
Passive View
PresenterXX
ViewX
Presenter Model
PresenterXX
ViewX
MVVM
PresenterXX
ViewX
ModelDatabinding
MVC
ControllerXX
ViewX
下面是上面讨论内容的图形化比较。
首先以上所有模式都是MVC的变种。换句话说，所有MVP模式都是扭曲的MVC。我们将首先比较MVC和MVP，之后我们将比较不同的MVP变种。
下面是MVP优于MVC的情况.
UI单元测试：如果你的项目对UI有自动化压力单元测试，那么MVP优于MVC，因为MVP的展示器类与所有UI逻辑隔离。展示器是UI的完全模拟，因此它可以使用VSTS测试套件或NUNIT单独进行单元测试。
视图有细微不同：如果你的应用本质上视图对不同的数据可复用，那么MVC就够了。特别是应用更注重报告。比如你有两个视图，几乎一样分别“按月销售”和“按年销售”。两个报告使用同一个ASPX页面显示不同的模型。那么如果你的应用有相同的UI，使用MVC的变种是个好选择。特别是本质上是面向报告的应用，MVC优于MVP。
多UI支持：如果预见应用将使用不同而UI技术，MVP是个好选择。换句话说，应用既支持Window还支持Web，优选MVP。它将帮助你提高展示器类的复用性。
复杂的屏幕：如果有许多复杂的用户交互，MVC会变得复杂，因为最终每个交互会有许多控制器类。MVP是更好的选择，因为你可以封装这些复杂的逻辑到一个类，并可以分开测试来确保无bug。
技术使用：技术是一个非常重要的因素。如果技术支持架构构建自动化，使用相应的模式就变得更有意义。例如你使用纯ASP.NET，应用不带Silverlight或WPF，使用MVP会更理智。ASP.NET页面期望在其他代码处理控制事件，而MVC则期望在控制器中处理事件。因此最终我们要重写全部的事件处理代码，因为ASP.NET控制着控制器。如果你使用Silverlight或WPG，它们有很好的丙丁支持，这使得MVP更适合。在另一方面，如果你有微小的变化，你也有3.5作为框架，你可以使用MVC框架，自动满足你的需求。
选MVC还是MVP的60%是技术选择驱动的。
