当超越RAD(拖放和配置)构建用户界面的方式时,许多工具鼓励您可能会遇到三种设计模式,称为Model-View-Controller、Model-View-Presenter和Model-View-ViewModel。我的问题分为三个部分:
在MVP中,Presenter 包含 View 的 UI 业务逻辑。View 委托的所有调用都直接发送给 Presenter。Presenter 也直接与 View 解耦,并通过接口与其对话。这是为了允许在单元测试中模拟视图。MVP 的一个共同属性是必须有大量的双向调度。例如,当有人单击“保存”按钮时,事件处理程序将委托给 Presenter 的“OnSave”方法。保存完成后,Presenter 将通过其接口回调 View,以便 View 可以显示保存已完成。
MVP 往往是在 WebForms 中实现分离表示的一种非常自然的模式。原因是视图总是首先由 ASP.NET 运行时创建。
被动视图:视图尽可能愚蠢,包含几乎为零的逻辑。Presenter 是与 View 和 Model 对话的中间人。View 和 Model 完全相互屏蔽。Model 可能会引发事件,但 Presenter 订阅它们以更新 View。在 Passive View 中没有直接的数据绑定,相反,View 公开了 Presenter 用来设置数据的 setter 属性。所有状态都在 Presenter 而不是 View 中管理。
监督控制器:演示者处理用户手势。View 通过数据绑定直接绑定到 Model。在这种情况下,Presenter 的工作是将 Model 传递给 View,以便它可以绑定到它。Presenter 还将包含诸如按下按钮、导航等手势的逻辑。
在MVC中,Controller 负责确定显示哪个 View 以响应任何操作,包括应用程序加载的时间。这与 MVP 不同,MVP 中的操作通过 View 路由到 Presenter。在 MVC 中,视图中的每个操作都与对控制器的调用以及操作相关联。在 Web 中,每个操作都涉及对 URL 的调用,在该 URL 的另一端有一个控制器进行响应。一旦该控制器完成其处理,它将返回正确的视图。该序列在应用程序的整个生命周期中以这种方式继续:
视图中的操作 -> 调用控制器 -> 控制器逻辑 -> 控制器返回视图。
MVC 的另一大区别是视图不直接绑定到模型。视图只是呈现并且是完全无状态的。在 MVC 的实现中,视图通常不会在后面的代码中包含任何逻辑。这与绝对必要的 MVP 相反,因为如果 View 不委托给 Presenter,它将永远不会被调用。
要查看的另一种模式是演示模型图案。在此模式中,没有 Presenter。相反,视图直接绑定到表示模型。演示模型是专门为视图制作的模型。这意味着该模型可以公开永远不会放在域模型上的属性,因为这违反了关注点分离。在这种情况下,Presentation Model 绑定到域模型并可能订阅来自该模型的事件。然后 View 订阅来自 Presentation Model 的事件并相应地更新自己。演示模型可以公开视图用于调用操作的命令。这种方法的优点是您可以从根本上完全删除代码隐藏,因为 PM 完全封装了视图的所有行为。