2

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

表单定义将如下所示，

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

每个IViewN都有不同的功能 - 例如，一个用于可视化数据变化比较，一个用于在网格中显示数据，一个用于汇总统计......

为什么这篇文章被否决了？评论你的理由。如果您不知道 MVP 是什么，请不要对这个问题投反对票。

4

2 回答 2

3

没有什么可以说明表单、视图和演示者之间存在一对一的关系。事实上，将表单的各个部分分解为多个“视图”（我最常在用户控件中看到这一点；但不一定非要如此）并且每个视图都有一个演示者，这是一件非常合理的事情. 最常见的形式是视图；但同样，这不是强制性的。

正如您所说，这意味着要避免使用一些可怕的全看\全做 Presenter，这会导致代码更具凝聚力并减少单元测试的麻烦。

于 2012-08-27T20:51:33.277 回答
1

如果我理解正确，您正在使用旧版应用程序和现有屏幕。在这里，您需要添加一些新功能。如果是这种情况，那么添加必须已经有可用于此屏幕的模型、演示者和视图。如果是这种情况，您别无选择，只能继续使用相同的架构，即使您的新功能使 View 和 Presenter 变得巨大。

但如果我错了，你自己实现了屏幕，那么你可以用他们自己的模型、演示者和视图来引入用户控件。但是请确保您的用户控件彼此独立，否则在用户控件之间建立桥梁以在它们之间进行通信将再次成为问题和混乱。

但老实说，即使文件很大，我也更愿意为此任务创建一个演示者和视图。通常，用户控件用于创建可在多个地方使用的通用控件。使用您的方法，如果您正在创建的用户控件之间存在大量通信，您可能会折腾。但是，是的，如果用户控件的创建有一个很好的计划，那么这可以得到缓解。但对我来说，最好只有一个演示者和视图，除非它们处于紧密耦合的情况。当你有像 resharper 这样的插件时，大文件不应该成为问题。

于 2012-08-21T11:29:49.070 回答