Question

我们正试图在（虚拟）所有新开发工作中使用Model-View-Presenter模式。

我坚信有一个框架可以帮助人们满足设计要求，我们有一些内部框架可用于各种不同的组件（日志记录，电子邮件发送等），所以我想尝试一些开发了一种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 类，该类继承自{{ 1}}抽象类。

正如您所看到的，我正在使用.NET泛型，以便开发人员在处理演示者时可以强大地键入View（最后是从演示者继承的类）。

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

Presenter

正如我所说，我非常喜欢这样，有编译器强制输入，强类型视图和MVP- 类似模式。

有些人对实现并不满意，因为它在演示者和观点之间有1对1的关系，严格来说这不是MVP的意图。

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

我试图从MVP到太远的框架被称为MVP吗？是否需要向演示者提供多个视图MVP的主要目标？是否有可能拥有一个支持n视图的真正的.NET MVP框架？

Answer 1

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

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

Answer 2

您可能会发现Implementing MVC with Windows Forms的答案很有帮助，因为他们在实施MVC和MVP时讨论了不同的选项

MVP模式，主持人有多少观看次数？

2 个答案: