【问题标题】:MVP pattern, how many views to a presenter?MVP 模式,一个演示者有多少视图?
【发布时间】:2009-05-13 05:05:04
【问题描述】:

我们正在尝试让模型-视图-演示者模式用于(实际上)我们承担的所有新开发工作。

我坚信有一个框架可以帮助人们满足设计要求,我们有一些用于各种不同组件(日志记录、电子邮件发送等)的内部框架,所以我正在尝试获得一些开发的一种 MVP 框架。

我已经设法为不熟悉 MVP 的人提供了一些易于使用的东西,并且与 我们目前的工作方式相差不远。问题在于它正在建立 1 个视图与 1 个演示者的关系。

以下是框架的大致轮廓:

public abstract class Presenter<TView> where TView : IView {
  public virtual T View { get; set; }

  public virtual void Setup(TView view) {
    this.View = view; 
  }
}

public interface IView { }

它的基本工作方式是任何创建的 View 都继承自 IView 接口,并传递给继承自 Presenter 抽象的 Presenter 类类。

如您所见,我正在使用 .NET 泛型,以便开发人员在使用 Presenter(然后最终是从 Presenter 继承的类)时对 View 进行强类型化。

所以我可以像这样设置一个基本的登录组件:

public class Login : Presenter<ILogin> {
  public override Setup(ILogin view){
    base.Setup(view);
    this.View.Login += new EventHandler(login);
  }
  void login(object sender, EventArgs e) { ... }
}

public interface ILogin : IView {
  string Username { get; set; }
  string Password { get; set; }
  event EventHandler Login;
}

所以正如我所说的,我非常喜欢这个,有编译器强制类型、强类型视图和 MVP-like 模式。

尽管有些人对实现不太满意,因为它在演示者和视图之间具有一对一的关系,严格来说这不是 MVP 的本意。

我质疑这个论点的有效性,在我一直在跟踪这个框架的几个项目中(从大中型项目)我没有找到任何好的例子,我认为“我需要有多个视图这位主持人”。当我看到可以在多个视图之间共享的功能时,我会质疑它是否应该与特定的演示者相关联,或者是否应该在一个更中立的类中。

我试图实现的框架是否离 MVP 太远而不能被称为 MVP? MVP 的主要目标是需要对演示者有多个视图吗?是否有可能拥有一个真正支持 n-view 的 .NET MVP 框架?

【问题讨论】:

    标签: .net mvp


    【解决方案1】:

    我认为您的方法没有问题。您不需要在演示者和视图之间建立一对多的关系 - 通常每个演示者只有一个视图。 MVP 背后的想法是将演示者与视图解耦,这样您就可以在需要时更轻松地切换视图(例如,同时支持 Web 应用程序和桌面应用程序),但这并不意味着你必须让它动态化。

    一个建议:我通常将IView 作为构造函数参数提供给PresenterIView 的具体实现然后创建演示者(通过硬编码 new Presenter (this) 或使用 IoC 容器来获取它。

    【讨论】:

    • 我可以看到将视图作为 ctor 参数传递的优点,但大多数用途是在 Web 应用程序上,我有另一个类,然后将 UserControl 与演示者一起包装(因此您可以在 UI 上继承级别)
    【解决方案2】:

    Implementing MVC with Windows Forms 的答案可能对您有所帮助,因为他们讨论了实现 MVC 和 MVP 时的不同选项

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2014-07-07
      • 1970-01-01
      • 1970-01-01
      • 2020-07-04
      • 2018-12-03
      相关资源
      最近更新 更多