如何构建 C# WinForms 模型-视图-呈现器（被动视图）程序？

Question

我正在设计一个具有以下基本思想的 GUI（类似于 Visual Studio 的基本外观和感觉建模）：

1. 文件导航
2. 控制选择器（用于选择在编辑器组件中显示的内容）
3. 编辑器
4. 记录器（错误、警告、确认等） .)

现在，我将使用 TreeView 进行文件导航，使用 ListView 来选择要在编辑器中显示的控件，使用 RichTextBox 进行记录器。编辑器将有 2 种类型的编辑模式，具体取决于在 TreeView 中选择的内容。编辑器要么是一个用于手动编辑文件内文本的 RichTextBox，要么是一个带有拖放 DataGridView 和子文本框的面板，用于在此面板中进行编辑。

我试图遵循被动视图设计模式，将模型与视图完全分离，反之亦然。该项目的本质是我添加的任何组件都可以编辑/删除。因此，我需要独立于给定的控制到下一个。如果今天我使用 TreeView 进行文件导航，但明天我被告知使用其他东西，那么我想相对轻松地实现一个新控件。

我根本不明白如何构建该程序。我了解每个控件一个演示者，但我不知道如何使其工作，以便我有一个带有控件（子视图）的视图（程序的整个 GUI），以便整个视图以及单个视图都可以替换反映我的模型的控件。

在按被动视图标准应该是轻量级的主视图中，我是否单独实现子视图？如果是这样，假设我有一个接口 INavigator 来抽象 Navigator 对象的角色。导航器需要一个 Presenter 和一个 Model 来在导航器视图和主视图之间进行操作。我觉得我在某个地方迷失了设计模式术语。

可以在此处找到最相似的问题，但它没有回答我的问题足够详细。

有人可以帮助我理解如何“构建”这个程序吗？我很感激任何帮助。

谢谢，

丹尼尔

Answer 1

抽象是好的，但重要的是要记住，在某些时候某物必须了解一两件事的一两件事，否则我们只会在上面放一堆精美抽象的乐高积木。地板而不是将它们组装成房子。

控制反转/依赖注入/flippy-dippy-upside-down-whatever-we're-calling-it-this-week 容器，例如 Autofac 确实可以帮助将这一切拼凑在一起。

当我组装一个 WinForms 应用程序时，通常会得到一个重复的模式。

我将从配置 Autofac 容器的 Program.cs 文件开始，然后从中获取 MainForm 的实例，并显示 MainForm >。有些人称其为外壳、工作区或桌面，但无论如何它是具有菜单栏并显示子窗口或子用户控件的“表单”，当它关闭时，应用程序退出。

接下来是前面提到的MainForm。我在 Visual Studio 可视化设计器中执行一些基本操作，例如拖放一些 SplitContainers 和 MenuBar 等，然后我开始喜欢代码：我'我会将某些关键接口“注入”到 MainForm 的构造函数中，以便我可以使用它们，这样我的 MainForm 就可以编排子控件，而无需真正了解它们。

例如，我可能有一个 IEventBroker 接口，允许各种组件发布或订阅“事件”，例如 BarcodeScanned 或 ProductSaved。这允许应用程序的各个部分以松散耦合的方式响应事件，而不必依赖连接传统的 .NET 事件。例如，与我的 EditProductUserControl 一起使用的 EditProductPresenter 可能会显示 this.eventBroker.Fire("ProductSaved", new EventArgs(blah))< /code> 和 IEventBroker 将检查该事件的订阅者列表并调用它们的回调。例如，ListProductsPresenter 可以侦听该事件并动态更新它所附加的 ListProductsUserControl。最终结果是，如果用户将产品保存在一个用户控件中，则另一个用户控件的演示者可以做出反应并更新自身（如果它碰巧打开），而任一控件都不必知道彼此的存在，并且无需 MainForm 必须协调该事件。

如果我正在设计一个 MDI 应用程序，我可能会让 MainForm 实现一个 IWindowWorkspace 接口，该接口具有 Open() 和 Close( ） 方法。我可以将该界面注入到我的各个演示者中，以允许他们打开和关闭其他窗口，而无需直接了解 MainForm。例如，当用户双击 ListProductsPresenter 中数据网格中的一行时，ListProductsPresenter 可能想要打开 EditProductPresenter 和相应的 EditProductUserControl。代码>ListProductsUserControl。它可以引用 IWindowWorkspace（实际上是 MainForm），但它不需要知道这一点 - 并调用 Open(newInstanceOfAnEditControl) 并假设该控件以某种方式显示在应用程序的适当位置。 （MainForm 实现大概会将控件交换到面板上某处的视图中。）

但是 ListProductsPresenter 创建 该实例到底是如何的呢？ EditProductUserControl 的？ Autofac 的委托工厂在这里是一个真正的乐趣，因为您可以将委托注入到Presenter 和 Autofac 会自动将其连接起来，就像它是一个工厂一样（伪代码如下）：

public class EditProductUserControl : UserControl
{
    public EditProductUserControl(EditProductPresenter presenter)
    {
        // initialize databindings based on properties of the presenter
    }
}

public class EditProductPresenter
{
    // Autofac will do some magic when it sees this injected anywhere
    public delegate EditProductPresenter Factory(int productId);

    public EditProductPresenter(
        ISession session, // The NHibernate session reference
        IEventBroker eventBroker,
        int productId)    // An optional product identifier
    {
        // do stuff....
    }

    public void Save()
    {
        // do stuff...
        this.eventBroker.Publish("ProductSaved", new EventArgs(this.product));
    }
}

public class ListProductsPresenter
{
    private IEventBroker eventBroker;
    private EditProductsPresenter.Factory factory;
    private IWindowWorkspace workspace;

    public ListProductsPresenter(
        IEventBroker eventBroker,
        EditProductsPresenter.Factory factory,
        IWindowWorkspace workspace)
    {
       this.eventBroker = eventBroker;
       this.factory = factory;
       this.workspace = workspace;

       this.eventBroker.Subscribe("ProductSaved", this.WhenProductSaved);
    }

    public void WhenDataGridRowDoubleClicked(int productId)
    {
       var editPresenter = this.factory(productId);
       var editControl = new EditProductUserControl(editPresenter);
       this.workspace.Open(editControl);
    }

    public void WhenProductSaved(object sender, EventArgs e)
    {
       // refresh the data grid, etc.
    }
}

因此 ListProductsPresenter 了解 Edit 功能集（即，编辑 Presenter 和编辑用户控件）——这完全没问题，它们是齐头并进的——但它不需要知道 Edit依赖项 code> 功能集，而不是依赖 Autofac 提供的委托来解决它的所有这些依赖关系。

一般来说，我发现“演示者/视图模型/监督控制器”之间存在一对一的对应关系（我们不要太关注差异，因为最终它们都非常相似）和“ 用户控件/表单”。 UserControl 在其构造函数中接受演示者/视图模型/控制器，并根据需要进行数据绑定，尽可能地遵循演示者。有些人通过界面（例如 IEditProductView）向演示者隐藏了 UserControl，如果视图不是完全被动的，这可能会很有用。我倾向于对所有内容使用数据绑定，因此通信是通过 INotifyPropertyChanged 完成的，无需费心。

但是，如果演讲者无耻地与观点联系在一起，你的生活就会变得更加轻松。对象模型中的属性是否与数据绑定不匹配？公开一个新属性就是如此。您永远不会拥有具有同一种布局的 EditProductPresenter 和 EditProductUserControl，然后想要编写与同一演示器一起使用的新版本的用户控件。您只需编辑它们，它们的所有意图和目的都是一个单元，一个功能，演示者仅存在，因为它很容易进行单元测试，而用户控件则不然。

如果您希望某个功能可替换，则需要将整个功能抽象化。因此，您可能有一个与 MainForm 对话的 INavigationFeature 接口。您可以拥有一个实现 INavigationFeature 并由 TreeBasedUserControl 使用的 TreeBasedNavigationPresenter。您可能有一个 CarouselBasedNavigationPresenter，它也实现 INavigationFeature 并由 CarouselBasedUserControl 使用。用户控件和演示者仍然齐头并进，但是您的 MainForm 不必关心它是否与基于树的视图或基于轮播的视图交互，并且您可以交换它们在 MainForm 不知情的情况下就被淘汰了。

最后，你很容易让自己感到困惑。每个人都是迂腐的，并使用略有不同的术语来表达相似的架构模式之间的微妙（通常是不重要的）差异。以我的拙见，依赖注入对于构建可组合、可扩展的应用程序确实有奇迹，因为耦合被降低了。将功能分离为“呈现器/视图模型/控制器”和“视图/用户控件/表单”对于质量来说确实是奇迹，因为大多数逻辑都被引入到前者中，从而可以轻松进行单元测试；将这两个原则结合起来似乎确实是您正在寻找的，您只是对术语感到困惑。

或者，我可能已经充满了它。祝你好运！

Answer 2

我知道这个问题已经有近两年的历史了，但我发现自己处于非常相似的情况。和你一样，我在互联网上搜索了好几天，但没有找到适合我需求的具体例子 - 我搜索的越多，我一遍又一遍地回到相同的网站，直到我有大约 10 页紫色的页面谷歌链接！

不管怎样，我想知道你是否想出了一个令人满意的解决方案来解决这个问题？我将根据我上周读到的内容概述到目前为止我是如何做到这一点的：

我的目标是：
被动形式，演示者优先（演示者实例化表单，因此表单不知道其演示者）
通过在表单（视图）中引发事件来调用演示者中的方法

应用程序有一个 FormMain，其中包含 2 个用户控件：

ControlsView（有 3 个按钮）
DocumentView（第 3 方图像缩略图查看器）

“主窗体”包含一个用于常用文件保存内容等的工具栏，仅此而已。
“ControlsView”用户控件允许用户单击“扫描文档”
它还包含一个树视图控件来显示文档和页面的层次结构
“DocumentView”显示扫描文档的缩略图

我真的觉得每个控件都应该有自己的 MVP 三元组以及主窗体，但我希望它们都引用相同的模型。我只是不知道如何协调控件之间的通信。

例如，当用户单击“扫描”时，ControlsPresenter 负责从扫描仪获取图像，我希望它在从扫描仪返回的每个页面时将页面添加到树视图中 - 没问题 - 但我也想要缩略图同时出现在 DocumentsView 中（问题是演示者彼此不认识）。

我的解决方案是让 ControlsPresenter 调用模型中的方法以将新页面添加到业务对象中，然后在模型中引发“PageAdded”事件。

然后，我让 ControlsPresenter 和 DocumentPresenter “监听”此事件，以便 ControlsPesenter 告诉它的视图将新页面添加到树视图，而 DocumentPresenter 告诉它的视图添加新的缩略图。

总结一下：

控制视图 - 引发事件“ScanButtonClicked”

控制演示者 - 听到该事件，调用 Scanner 类来 AcquireImages，如下所示：

GDPictureScanning scanner = new GDPictureScanning();

IEnumerable<Page> pages = scanner.AquireImages();
foreach (Page page in pages)
{
m_DocumentModel.AddPage(page);                
//The view gets notified of new pages via events raised by the model
//The events are subscribed to by the various presenters so they can 
//update views accordingly                
}

扫描每个页面时，扫描循环调用“yield return new Page(PageID)”。
上述方法调用m_DocumentModel.AddPage(page)。
新页面将添加到模型中，从而引发一个事件。
两者都控制演示者和文档演示者“听到”事件并相应地添加项目。

我不太“确定”的是所有演示者的初始化 - 我在 Program.cs 中执行此操作，如下所示：

static void Main()
{
Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);

IDocumotiveCaptureView view = new DocumotiveCaptureView();
IDocumentModel model = new DocumentModel();
IDocumotiveCapturePresenter Presenter = new DocumotiveCapturePresenter(view, model);
IControlsPresenter ControlsPresenter = new ControlsPresenter(view.ControlsView, model);
IDocumentPresenter DocumentPresenter = new DocumentPresenter(view.DocumentView, model);

Application.Run((Form)view);                                                         
}

不确定这是好、坏还是无关紧要！

不管怎样，关于一个两年前的问题的一篇文章是多么巨大——不过最好能得到一些反馈......