0

根据 Martin Fowler 的 Presentation Model 注释以及有关 Presentation Model 的 MSDN 文档，解释说 Presentation Model 类应该不知道 UI 类，类似地，Business Model 类应该不知道 Presentation Model 类。

UI 应该与 Presentation Model 进行广泛的数据绑定，Presentation Model 反过来将与一个或多个 Domain/Business Model 对象协调以完成工作。Presentation Model 基本上以一种促进 UI 中最大数据绑定的方式呈现 Domain Model 数据，允许 UI 做出尽可能少的决策，从而提高 Presentation 行为的可测试性。这也使得表示模型类是通用的，即与任何特定的 UI 技术无关。

现在，考虑有一个 List 表单（比如 CustomerList）和另一个 Root 表单（比如 Customer），还有一个允许通过单击按钮从 CustomerList 表单编辑客户的用例。

为了讨论的简单，考虑当从菜单打开客户列表（即点击客户菜单）并且从菜单点击事件中显示客户列表时发生了一些操作。

现在根据上述用例，我需要从客户列表中打开客户根 UI（单个客户）。我怎么做？

  1. 在编辑按钮的单击事件中构建必要的对象（BusinessModel、PresentationModel、UI）并从那里调用 CustomerEdit UI？

  2. 从演示模型类构建 CustomerEdit UI 并从演示模型显示 UI？这可以通过以下两种方式中的任何一种来完成 - a. 按照以下顺序创建对象 DomainModel->PresentationModel-UIForm b. 使用 Unity.Resolve(); 无论哪种方式，都违反了表示模型​​，因为 P 模型现在必须引用 CustomerEdit 所在的具体 UI 程序集。此外，P 模型必须直接引用和使用 WinForm，使其与 UI 技术无关。

尽管这些违规行为在理论上是可以忽略的，但我仍然会征求社区对我是否走错方向的意见。请建议是否有更好的方法从列表（父）表单中调用子表单。

  • 拉贾希
4

2 回答 2

0

您的目标通常是系统不同部分之间的松散耦合，以便更易于维护。例如，这意味着您的模型不应该知道它与之通信的确切类型。它应该只知道所需的接口。

当您的模型在您的 UI 或业务逻辑层中引用某些东西时，没有什么不好或奇怪的，只要它使用接口而不是特定类型进行操作。

于 2010-04-25T21:31:11.393 回答
0

将IEditCustomerService 注入到CustomerList 的PresentationModel 中怎么样，如果应该编辑选定的Customer，则会调用该模型。然后，该服务要么自己“构建必要的对象”，要么将此任务委托给 IViewManagerService，后者知道哪些 UI 可用于编辑实体，哪个应该用于特定的 UI，以及如何构建帽子 UI 组件. 当然，您也可以通过将 IViewManagerService 直接注入 PresentationModel 来避免一种间接方式，或者您可以使用 DI 容器来解决它。

另一种可能性是让 IViewManagerService 实现监听由 CustomerList 的 PresentationModel 触发的 EditCustomerEvents。

于 2011-07-02T10:17:57.140 回答