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