MVP和多个用户控件

SwD*_*n81 17 c# oop mvp user-controls design-patterns

我正在尝试使用MVP模式,我遇到了一个设计问题.我正在开发一个具有多个UserControl的应用程序.UserControls本身彼此无关,只代表实际模型的子集.根据我的阅读,人们倾向于说每个视图应该使用一个Presenter.这似乎有道理,但如果我有30个UserControls,我真的想要30个演示者吗?另一方面,如果我有1个Presenter和1个View代表整个"应用程序"视图,那么我将拥有膨胀的View和Presenter界面.然后每个View都必须实现与它无关的方法.我的问题是,有没有更好的方法来处理多个UserControls,或者我应该为每个View创建一个Presenter?

Nik*_*vic 18

您应该为每个控件做一个演示者,因为:

  • 这将允许您进行集中的单元测试,仅处理该控件
  • 由于您不需要支持包含所有控件的表示逻辑联合的巨型演示者,因此可维护性得到提高
  • 这可以防止在多个页面上具有相同控制的情况下的冗余
  • 当页面执行特定于容器的角色时,通过让控件专注于其特定逻辑来增加SRP:

通常提到的两个问题与"每个控件的演示者"的决定有关:

  • 共享上下文是一个问题,因为所有控件只显示相同页面数据上下文的不同部分,这种情况可能看起来像一个有问题的用例,导致每个控件中的大量数据检索冗余代码.这很容易通过依赖注入来解决,其中页面(或控制器)执行单个数据检索,然后将数据上下文对象注入每个presenters\views(通常实现一些启用它的接口).对于MV-VM模式(Silverlight,WPF),可以通过数据绑定实现相同的效果,页面将设置其DataContext,然后从视图本身使用
  • 同一页面上的视图之间的通信是第二个问题,可以使用几种方法轻松解决:
  • 控件是发布页面订阅的事件,然后直接调用其他控件中的适当方法(页面是所有控件的容器,意味着它知道所有成员)
  • 观察者设计模式
  • 事件聚合器模式

在这些方法中的每一个中,控件彼此通信而不彼此了解


Cha*_*hap 14

将一个对象中相关的代码分组会更有意义.因此,在这种情况下,如果视图是相关代码的特定分组,那么演示者也将模仿这些分组.要为不同视图创建"全局"演示者,可以将不相关的代码分组到一个对象中.它肯定会使演示者的界面变得臃肿.查看单一责任原则.

现在,您可以拥有一个Presenter Manager类,它可以让您通过继承访问每个Presenter接口(如接口隔离原则状态)(具有实现许多演示者接口的全局具体演示者......这违反了单一责任) )或聚合(为每个接口提供单独的演示者并获取函数......因此全局接口将是get函数)或两者的组合(全局演示者在某种程度上是适配器).

我认为最好的解决方案只有30个不同的主持人.

  • 如果您有共享数据需要多个控件使用,则应该有一个单独的层为其提供数据.最简单的可能是一些datafetcher对象(或对象)在创建时传递到每个控件的演示者,他们可以在需要时请求所需的数据. (6认同)