我们一直在使用MVP模式和Winforms取得了相当大的成功。但是，一个关于MVP的问题总是突然出现：
演示者的良好粒度是什么？
我的意思是：使用Winforms，细粒度通常对用户控件非常有效。这样，在设计更复杂的GUI时，可以轻松地重用用户控件并将其用作构建块。但是，与演示者具有相同（精细）粒度似乎是一个问题。
一方面，粗粒度演示者阻碍了使用“插件”控件的能力，并且它违反了DRY原则：多个演示者通常需要实现相同的逻辑（填充）例如，客户列表，由多个更复杂的控件使用。
另一方面，细粒度演示者似乎限制了在不同情况下重用控件的能力。例如，编辑视图有时可能需要立即保存客户;有时它需要将它与其他东西联系起来;有时只需要验证它;等等。它通常取决于更复杂的控制。但也有相当多的共同行为。
请注意，在这两种情况下，都可以实现1-presenter-1-view。什么被认为是“1视图”的变化。
使用MVP和Winforms通常被认为是演示者粒度的最佳做法？
免责声明：我们主要使用监督控制器，但我认为它也适用于被动视图。很抱歉这个问题很长。
答案 0 :(得分：2)
我们在所有客户中使用MVP，这肯定是不止一次出现的对话。我们的课程和演示者背后的代码应该有多干净？话虽如此，我们选择使用粗粒度的演示者方法。基本上，每个表单都有自己的演示者，并且只能使用其视图获取和设置特定表单上任何控件的属性。填充控件（例如，调用db来填充组合框）位于公共服务类中。用户输入数据的任何验证都位于BO类中，该类可以由任何和/或所有演示者重用。我希望这会有所帮助。
答案 1 :(得分：2)
在我的CAD-CAM系统中，我的演示者不使用用户控件。用户控件驻留在视图中，该视图驻留在EXE程序集中，该程序集实现演示者使用的视图接口。
如果要显示客户列表，我将其交给具有DisplayCustomerList的视图，并使用它所需的任何用户控件组合来显示客户列表。如果多个视图以相同的方式显示客户列表，那么在ExE / View程序集中，它们共享用户控件或类来执行此操作。那个班级不会超出那个集会。
我们的软件适用于运行多种不同类型的金属切割机。因此，我们非常重视能够扯掉UI并用完全不同的UI（对应于不同的机器）替换它。所有这些UI都引用了同一组核心程序集。
层次结构如下所示
查看EXE 演示者实施 命令组件 - 命令由演示者执行，用于修改模型 演示者界面 模型装配
一边是可加载的程序集，它们定义动态内容，例如可以加载哪些文件类型，报告，切割设备驱动程序等。这些可以实现模型程序集中的各种接口
我做的一件事是我不会为每个对话框推动一个视图演示者。如果对话框与命令紧密绑定，则在命令类的旁边定义，创建和使用它。有时，一组相关命令将共享一个对话框（例如文件处理）。
我在使用MVP时提出的基本问题是“如果想用其他东西完全替换表格，会发生什么？”。该问题的答案将确定您过于依赖特定用户控件或表单引擎的位置。
我的设置中最大的问题（也是我没有得到很好的答案）是当前的IDE和语言使得将用户控件绑定到数据库记录变得非常容易。它比任何其他设置都高效，它往往主导设计。我没有必要在我的CAD-CAM应用程序中处理这个问题，所以除了将数据集传递给视图并让它处理它之外，我没有任何答案。 This site有一些在这种情况下可能有用的模式。