使用Presentation Model处理父表单子表单关系的最佳实践

Question

根据Martin Fowler的演示模型说明以及有关演示模型的MSDN文档，解释说演示模型类应该不知道UI类，类似的业务模型类应该不知道Presentation Model类。 / p>

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

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

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

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

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

2. 从Presentation Model Class构建CustomerEdit UI并从演示模型中显示UI？ 这可以通过以下两种方式中的任何一种来完成 - 一个。按以下顺序创建对象DomainModel-＆gt; PresentationModel-UIForm 湾使用Unity.Resolve（）; 无论哪种方式，都会违反Presentation Model，因为P模型现在必须参考CustomerEdit所在的具体UI程序集。此外，P模型必须直接引用和使用WinForm，使其与UI技术无关。

尽管违规行为在理论上是可以忽略的，但我仍然会寻求社区对我是否出错方向的看法。请建议是否有更好的方式从列表（父母）表格中拨打儿童表格。

• Rajarshi

Answer 1

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

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

Answer 2

如何将IEditCustomerService注入到CustomerList的PresentationModel中，以便在编辑选定的Customer时调用它。然后，该服务自己“构建必要的对象”，或者将此任务删除到IViewManagerService，IViewManagerService知道哪些UI可用于编辑实体，哪一个应该用于特定的UI，以及如何构建帽子UI组件。当然，您也可以通过将IViewManagerService直接注入PresentationModel来避免一个间接，或者您可以使用DI容器来解决它。

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