MVP模式，一个主持人有多少浏览量？

我们正在尝试将模型-视图-呈现器模式用于（几乎）我们承担的所有新开发工作。

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

我已经成功地整合了一些东西，对于那些不熟悉 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抽象类。

正如您所看到的，我正在使用 .NET 泛型，以便开发人员在处理演示器（以及最终从演示器继承的类）时可以对视图进行强类型化。

所以我可以设置一个基本的登录组件，如下所示：

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图案。

但有些人对实施不太满意，因为它在演示者和视图之间具有 1 对 1 的关系，严格来说这不是 MVP 的本来面目。

我质疑这个论点到底有多有效，在我一直跟踪这个框架的几个项目（从中型到大型项目）中，我没有找到任何好的例子，我认为“我需要为这个演示者提供多个视图” 。当我看到可以在多个视图之间共享的功能时，我怀疑它是否应该与特定的演示者绑定，或者是否应该位于更中立的类中。

我想要实现的框架是否离 MVP 太远而不能称为 MVP？ MVP 的首要目标是对演示者有多种观点的需求吗？是否有可能拥有一个真正的支持 n 视图的 .NET MVP 框架？

我不认为你的方法有问题。您并不严格需要在演示者和视图之间建立一对多的关系 - 通常每个演示者只有一个视图。 MVP 背后的想法是解耦视图中的演示者，以便您可以在需要时更轻松地切换视图（例如，支持 Web 应用程序和桌面应用程序），但这并不意味着您必须使其动态。

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