MVP和多个用户控件
我正在尝试使用MVP模式，我遇到了一个设计问题。 我正在开发一个具有多个UserControl的应用程序。 UserControls本身彼此无关，只代表实际模型的一个子集。 根据我的阅读，人们倾向于说每个视图应该使用一个Presenter。 这似乎有道理，但如果我有30个UserControls，我真的想要30个演示者吗？ 另一方面，如果我有1个Presenter和1个View代表整个“应用程序”视图，那么我将拥有膨胀的View和Presenter界面。 然后每个View都必须实现与它无关的方法。 我的问题是，有没有更好的方法来处理多个UserControls，或者我应该为每个View创建一个Presenter？
将一个对象中相关的代码分组会更有意义。 因此，在这种情况下，如果视图是相关代码的特定分组，那么演示者也将模仿这些分组。 要为不同的视图创建“全局”演示者，可以将不相关的代码分组到一个对象中。 它肯定会使演示者的界面变得臃肿。 查看单一责任原则 。
现在，你可以拥有一个Presenter Manager类，它可以让你通过inheritance访问每个presenter接口， 比如接口隔离原则状态（有一个实现许多presenter接口的全局具体演示者……这违反了单一的责任）或聚合（为每个接口提供单独的演示者并获取函数……因此全局接口将是get函数）或两者的组合（全局演示者有点像适配器）。
我认为最好的解决方案只有30个不同的主持人。
你应该为每个控件做一个演示者，因为：
- 这将允许您进行集中的unit testing，仅处理该控件
- 由于您不需要支持包含所有控件的表示逻辑联合的巨型演示者，因此提高了可维护性
- 这可以防止在多个页面上具有相同控制的情况下的冗余
- 当页面执行特定于容器的角色时，通过让控件专注于其特定逻辑来增加SRP ：
通常提到的两个问题与“每个控件的演示者”的决定有关：
- 共享上下文是一个问题，因为所有控件只显示相同页面数据上下文的不同部分，这种情况可能看起来像一个有问题的用例，导致每个控件中的大量数据检索冗余代码。 这很容易通过dependency injection来解决，其中页面（或控制器）执行单个数据检索，然后将数据上下文对象注入每个presenters \ views（通常实现一些启用它的接口）。 在MV-VM模式（Silverlight，WPF）的情况下，可以通过数据绑定实现相同的效果，其中页面将设置其DataContext，然后将从视图本身使用
- 同一页面上的视图之间的通信是第二个问题，可以使用几种方法轻松解决：
- 控件是发布页面订阅的事件 ，然后直接调用其他控件中的适当方法（页面是所有控件的容器，意味着它知道所有成员）
- 观察者设计模式
- 事件聚合器模式
在这些方法中的每一个中，控件彼此通信而不彼此了解
每个View都不必实现相同的界面…为什么不为每个控件定义接口，并为整个屏幕安装一个包含所有控件的Presenter？ Presenter可以根据每个视图所需的接口定义事件，将每个视图上的事件“连线”到Presenter上的相应事件处理程序（如果您正在进行MVPC，则可以在控制器上）。 您可能还需要另一个界面来表示所有视图需要共同访问的Presenterfunction…
- 如果您正在进行MVPC，那么在Controller中查看影响模型的事件将被“处理”，而只影响View其他部分的View事件将在Presenter上处理。
老问题，但是我要填写并且必须不同意其他答案：你不希望每个UserControl有一个演示者，比你想要在每个UserControl上进行unit testing – 这将是一个盲目的滥用设计模式。
UserControl不是View。
您的应用程序的每个逻辑区域应该有一个演示者; 每个人如何分手 – 多少控件，什么表明什么 – 仅仅是构成的一个问题。