架构模式的对比--MVP(SC),MVP(PV),PM,MVVM and MVC
简介
这篇文章将比较四种重要的架构表现模式，MVP（SC），MVP（PV），PM，PVVM，MVC。很多开发者都对这些模式感到困惑，不知道我们该如何正确地应用它们。这篇文章将以介绍表现模式的背景为开头，逐步解释这几种模式。接着我们会进一步讨论状态，逻辑，同步性等问题。最后我们会详细地介绍每个模式并总结它们之间有什么不同。
背景：表现模式 (Presentation patterns)
与用户界面 (UI) 相关的最大的问题就是大量的凌乱的代码，主要是由这两个因素造成的，首先是用户界面使用复杂的逻辑用于维护界面相关对象，其次也包含了应用程序状态的维护。表现模式 (Presentation patterns) 就是围绕如何移除用户界面的复杂性，让界面更加简洁和可管理而产生的，下图就是常见表现模式的种类与分类：
表现模式主要分成三种类别：MVP ( Model view presenter ) , MVC ( Model view controller) and PM (presenter model). MVP被进一步分为 监视控制器模式(supervising controller) 和被动视图模式(passive view). PM进一步分成了两个技术的特定模式： MVVM for silverlight 和 MVVM for WPF.
用户界面的3大问题：状态 (State) ， 逻辑 (Logic) ，同步 (Synchronization)
状态 (State) ： 状态/数据是用户界面最关心的问题之一。状态是用户界面数据的当前快照，在 Web 应用中，可能是 Session 级别的一个变量，在 Windows 应用中， 则可能只是界面级别的数据。 用户界面包含的状态越多， 则用户界面越复杂。
逻辑 (Logic) ： 用户界面往往包含界面逻辑，例如维护文本框、组合框或者其它任何界面元素，用户界面中这种逻辑越多，则用户界面越复杂。
同步 (Synchronization) ： 用户界面通常需要和业务组件协作，因此用户界面需要在界面元素与业务对象之间同步数据，如果用户界面包含的同步任务越多，则用户界面越复杂。
这三大问题与用户界面的关系如下图：
表现设计模式 (Presentation Design Pattern)
表现设计模式有助于解决上面列出的问题， 它的的基本逻辑就是创建一个额外的表现类 (Presenter) ，用来解决用户界面中复杂的逻辑，数据和同步的问题，从而使得用户界面变得简单明了。根据这个类承担责任的多少，决定了表现设计模式的类型，可能是 SC , PV , PM 等，也就是说，这个类型的成熟度决定了它将是那种设计模式。
有用的缩写
- V 视图 (View) 或者用户界面 (UI)
- P 包含界面逻辑的表现类 (Presenter class which has the UI logic.)
- L 用户界面逻辑
- S 用户界面的状态
- M 业务组件或业务对象
- SC 监视控制器 (Supervising controller)
- PV 被动视图 (Passive view)
- PM 表现模型 (Passive view)
监视控制器模式 (SC)
* 状态在视图中保存
* 表现类拥有复杂的表现逻辑，只关注简单的界面绑定逻辑，例如 WPF 或 Silverlight 等提供的绑定机制 (Presenter owns the complex presentation logic. Simple UI binding logic is taken care by using binding technologies like WPF binding and Silverlight binding. Anything complex is taken care presenter class. )
* 表现类关注视图
* 视图不关注表现类
* 视图通过数据绑定和业务模型进行关联
被动视图模式 (PV)
* 状态在视图中保存
* 所有的界面逻辑都被包含在表现类中
* 视图和业务模型完全独立，这种情况下需要一些在业务模型和视图之间进行同步数据的工作
* 表现类关注视图
* 视图不关注表现类
表现模型 (PM)
* 表现类包含逻辑
* 表现类包含状态
* 表现类代表抽象的用户界面
* 表现类不关注用户界面
* 视图关注表现类
* 视图与业务模型完全隔离
MVVM
* 继承自表现模型
* 状态存储在表现层中
* 逻辑存储在表现层中
* 表现层代表了一个抽象的UI视图
* 表现层不关注视图
* 视图关注表现层
* 视图与业务模型完全隔离
* 使用 WPF 以及 Silverlight 的绑定机制
MVC
* 没有表现类，有控制器 (Controller)
* 请求首先到达控制器
* 控制器负责绑定视图与业务模型
* 逻辑存在于控制器中
总结与对比
下表是这几种表现模式从状态，逻辑与同步的角度进行的对比
| 状态 | 逻辑 | 同步 | ||
| Supervising controller | ||||
| 表现类 | X | X | ||
| 视图 | X | |||
| 业务模型 | 视图和业务模型之间通过绑定进行连接。 | |||
| Passive View | ||||
| 表现类 | X | X | ||
| 视图 | X | |||
| Presenter model | ||||
| 表现类 | X | X | ||
| 视图 | X | |||
| MVVM | ||||
| 表现类 | X | X | ||
| 视图 | X | |||
| 使用 WPF 、Silverlight 的数据绑定机制 | ||||
| MVC | ||||
| 控制器 | X | X | ||
| 视图 | X | |||
再来一个图的对比
何时使用MVP和MVC
首先，以上所述的模式都是MVC模式的变种。也就是说MVP是MVC的分支。我们将首先比较MVC和MVP，然后再比较MVP的变种的差异。
以下为何时MVP会优于MVC。
UI单元测试(UI unit test) -- 如果你的项目将侧重于UI单元测试的自动化，那么MVP会优于MVC。因为MVP的模型层和所有的UI逻辑元素是完全隔离的。表现层完全仿制UI以便能用VSTS测试套件或者NUNIT单独地进行单元测试。
视图变化很小(Views are same with slight variations) -- 如果你的应用包含可以被不同数据重用的视图，那么MVC将会是一个好的选择。特别是当你的应用偏向于面向报表。比如说你有两个差不多一模一样的视图"Sales by month"和"Sales by year",这两个报表虽然使用不同的模型，但是都能被相同的ASPX页面展示。这种情况下MVC将是更好的选择。
多个UI支持（Multi UI support） -- 如果你觉得你的应用需要应用大量的UI技术，不管是Web应用上的UI还是Windows的UI，MVP将是个更好的选择。它能通过表现层的模型来帮你增强复用性。
复杂的界面（Complex Screens） -- 如果你的界面需要很多的用户交互，MVC将变得很复杂因为你需要用很多的控制器来处理每个交互。MVP是一个更好的选择因为你能用类来处理那些复杂的逻辑并单独地测试它以消除代码中的bug。
技术应用(Technology used) -- 技术是一个很重要的因素。如果你应用的技术为你的框架提供了自动化操作，那么构建它的时候将比使用表现模式更加有效。比如说，如果你只使用纯粹的没有Silverlight或者WPF的ASP.NET来创建你的应用，那么MVP将是更为明智的选择。ASP.NET页面希望控制事件能被后台的代码所处理而MVC则希望这些事件被控制器所处理。于是我们最终只能在控制器上重写所有在ASP.NET上的控制事件的代码。但是如果你使用silverlight和WPF，它们支持良好的绑定，能让MVP更好的工作。另一方面，
如果你拥有相同的只有很小的变化的视图层和.Net 3.5框架，你可以使用MVC框架来自动化操作以符合你的需求。
技术因素在选择MVC还是MVP的时候占了60%。
何时使用 SC , PV , PM and MVVM ?
待续。
原文链接：http://www.codeproject.com/Articles/66585/Comparison-of-Architecture-presentation-patterns-M
转载于:https://www.cnblogs.com/hedgehog-ZDH/archive/2012/10/19/2730362.html