Model-View-Presenter (MVP) 展现了一种关于 UI 模式的突破性思维方式，并明确了 UI 设计人员应 该在应用程序中保持独立。
但是，对 MVP 模式有许多种不同的解释。例如，有些人想当然地认为 MVP 模式明确表示 UI 体系结 构模式。这对于企业级应用程序来说，并不完全正确。与其他类型的 UI 应用程序相比，企业级应用程序 需要满足许多不同的需求，涉及更多相关方，更加复杂，而且更多地交叉依赖于其他系统（例如服务、其 他应用程序等）。这些独有的特征要求企业级应用程序的 UI 体系结构更强调灵活性、易维护性、可重用 性和实施一致性，并且要求业务功能与基础技术分离，从而避免依赖于特定的产品和供应商。
如果仅仅采用 MVP 模式本身作为企业级应用程序的 UI 体系结构模式，会出现一些问题。下面列出了 部分问题：
典型的企业级应用程序包含许多视图，一个视图中发生的事件可能会影响其他视图。例如，在一个屏 幕中单击一个按钮，可能会导致显示一个弹出窗口，同时可能会更新另一个屏幕的数据。谁负责控制这样 的屏幕流逻辑？这是否应该由每个视图的配对表示器控制？
在面向服务的体系结构 (SOA) 中，应用程序 UI 通常会通过服务来获取信息。例如，UI 可能需要调 用所生成的 WCF 服务客户端代理，以便调用 WCF 服务以获取数据。直接调用此服务客户端代理是不是一 种良好的表示器设计呢？如果这些服务采用不同的技术实现，或者如果服务模型被更改，应该如何设计 UI 体系结构，才能使这些变化对 UI 实现的影响降到最低？
根据这种思路，有些实现可能会在整个应用程序中使用所生成的服务客户端代理模型。这样做会不会 有什么风险？如果需要专用的 UI 模型，哪个部分负责在服务客户端代理模型与 UI 模型之间提供映射？
这些都已经不是新问题，而且已经引入了许多其他模式来弥补这些漏洞。例如，引入应用程序控制器 模式是为了承担控制导航流的责任。
我想，如果能够将这些零零散散的 MVP 扩展讨论收集到一起并绘制 UI 体系结构设计的整体视图，一 定会很有帮助。从企业级应用程序的角度来看这个问题，可以帮助 UI 架构师认识到 UI 设计所需的关键 部件并定义统一的模式来指导 UI 应用程序的实现。
本文通篇使用了术语“MVP 模式”，但实际上，原始的 MVP 模式已经被它的两种变体所取代：一种是 Passive View 模式，另一种是 Supervising Controller 模式。这两种模式分别适应不同的方案，并且 它们各有优缺点。图 1 中描述的 UI 体系结构主要基于 Passive View 模式并对其进行了扩展。这当然 不是说不能基于 Supervising Controller 模式来构成 UI 体系结构，而只是我的个人偏好而已。
图 1 基于 Passive View 模式的 UI 体系结构