MVP：一个复杂形式的多个视图/演示者（winforms）？

Question

我在遗留应用程序中为复杂表单添加了一些功能。它已经有一个巨大的形式，有很多控件和标签以及cs文件背后的巨大代码。我试图避免创建一个巨大的视图/演示者。为表单的每个功能添加视图（和演示者）是一个好习惯吗？有没有更好的解决方案？由于用户的要求，我无法将表单分成多种形式。

表单定义如下所示

public partial class frmMyForm 
    : IView1, IView2, IView3, IView4, IView5, 
      IView6, IView7, IView8, IView9, IView10
{
    ....

每个IViewN都是不同的功能 - 例如，一个用于视觉数据更改比较，一个用于显示网格中的数据，一个用于摘要统计...

---

为什么这篇文章被投票？评论你的理由。 如果你不知道MVP是什么，请不要投票。

Answer 1

没有任何内容表明表单，视图和演示者之间存在一对一的关系。实际上，将表单的各个部分分解为多个“视图”是完全合理的（我最常用的是用户控件;但它不一定是这样）并且每个视图都有一个演示者。最常见的是表格是观点;但同样，这不是强制性的。

正如你所说，这意味着要避免一些怪异的全看人/所有做的Presenter，这应该会导致更有凝聚力的代码并减少单元测试的麻烦。

Answer 2

如果我理解正确，您正在使用遗留应用程序和现有屏幕。在这里，您需要添加一些新功能。如果是这种情况，那么必须添加可用于此屏幕的模型，演示者和视图。如果是这种情况，那么您没有其他选择，但如果您的新功能使View和Presenter变得庞大，则继续使用相同的架构。

但如果我错了并且您自己实现了屏幕，那么您可以使用自己的模型，演示者和视图来引入用户控件。但要确保您的用户控件彼此独立，否则在用户控件之间建立桥梁以便在它们之间进行通信将再次成为一个问题和困惑。

但老实说，即使文件变得庞大，我也会更喜欢创建一个演示者并查看此任务。通常，用户控件用于创建可在多个位置使用的公共控件。使用您的方法，如果您正在创建的用户控件之间存在大量通信，则可以进行折腾。但是，如果用一个伟大的计划创建用户控件，那么可以放松一下。但对我来说，除非他们处于紧密耦合的情况，否则首选一个演示者和视图。当你帮助像resharper这样的插件时，巨大的文件应该不是问题。