如何在MVP模式中定义一组与数据模型的公共交互
本文关键字：一组 数据模型 交互 MVP 模式 定义 | 更新日期: 2023-09-27 18:04:11
我继承了一个WinForms应用程序，它在业务逻辑和UI控制之间的关注分离方面存在重大问题。这两者是如此紧密地交织在一起，如果不引入显著的回归，UI修改/扩展几乎是不可能的。
作为MVP重构提案的一部分，我面临的一个问题是如何最好地定义影响我们模型的操作。有很多这样的操作(例如，更新客户历史记录)被应用程序的多个领域所利用，所以我不想将模型交互直接编码到演示器中。
许多影响给定持久对象的操作已经封装在该对象中(尽管是静态方法)。我应该继续这种模式，重构方法以使方法基于实例，还是将方法拆分为一组独立的类api ?
编辑:我在这里真正要问的是:是否可以将影响模型的方法封装在定义模型的类中，或者我应该保留这些POCO，并在定义模型API的一组单独的类中实现这些方法?
当您使用MVP架构时，业务逻辑和UI不应该交织在一起。因为在业务逻辑和UI之间有一个表示器。Presenter只知道View的接口，并且Presenter订阅View的事件。这就是我们所知道的。你可以自由地改变视图上的控件——排列它们，替换它们，改变颜色——任何UI的东西。这些修改不会影响Presenter。当然，这些修改不会影响业务逻辑。
现在关于Presenter。它只是将UI事件转换为对Model的调用，然后通过IView接口更新UI。调用Model是什么意思?视情况而定。它可以是对业务逻辑所在的WCF等服务的调用。它可以是对应用程序或领域服务对象的调用，也可以是对存储库的调用(就领域驱动设计而言)。但是不应该有商业逻辑。呈现者是UI事件到模型调用的简单转换器。它可以创建一些DTO对象并将其分配给View，但没有真正的业务。
和模型。模型是所有那些类，由呈现者调用。这里是业务逻辑所在。业务逻辑不重复。如果您需要更新客户历史记录，那么它可以是CustomerRepository，或者像SalesService这样的服务对象。该对象由每个演示者调用，它需要更新客户历史记录。
建议-不要在业务操作中使用静态方法。它紧密地耦合了对象。它使得使用标准测试框架进行测试变得不可能。使用实例方法。实现接口。嘲笑他们。您的系统将变得松散耦合和可测试。这就是MVP模式的好处。