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