winforms 的复杂监督控制器示例答案

【问题标题】：Complex Supervising Controller examples for winformswinforms 的复杂监督控制器示例
【发布时间】：2009-07-09 02:26:10
【问题描述】：

很抱歉，如果以前有人问过这个问题，但我找不到任何帮助。

我想知道是否有人有任何使用监督控制器 MVP 模式创建的复杂 winform 的好例子。我读过很多例子，但它们真的很简单，只处理一种形式和一种模型。

我正在寻找的是一个示例，它显示了如何将数据从一个视图传递到另一个视图，以及通信线路应该在哪里以及应该绑定到什么。

对于狡猾的 UI 模型，我们深表歉意。基本上每个用户控件都有自己的演示者和模态层对象。

我需要做的是在用户控件 1 上输入文本框，使用服务对象（在用户控件 1 的演示者中）从数据库中获取正确的项目，并将其作为模式传递给用户控件 2 .

我的问题是：我是通过视图界面将模型传递给用户控件 2 还是传递给它的演示者？

抱歉，如果这有点难以理解，我只是不断看到人们说您可以使用带有使用 MVP 模式的用户控件的表单，但找不到任何关于如何在两者之间传递数据的示例。

编辑： 我已经制定了两个不同的是我认为我可以做到这一点：

和

我认为 Ex1 更好，因为它仍然让演示者负责。做他们想做的事。

你怎么看？

谢谢。

【问题讨论】：

【解决方案1】：

我将采用面向事件的发布/订阅方法来解决此问题。

模式是这样的：

用户在第一个视图上单击“编辑”按钮会触发一个带有单个参数（本例中为文本框的 ID、值）的事件（您可以将其称为命令）。比如说，将事件称为“EditRequested”。这是事件的“发布”，告诉任何想知道这已经发生的人和细节。实际发布可能在控制器/演示者中完成。
第二个视图的控制器/演示者监听上述事件，并在事件触发时采取相应的行动，加载数据并使用事件参数 (ID) 切换到编辑模式。这是模式的“订阅”部分。

理想情况下，这将使用事件聚合器来完成（CAB 和 Prism 都提供了一个），但您可能可以针对单个案例手动执行某些操作。事件聚合器消除了发布者和订阅者必须相互了解的需要，从而改善了松散耦合。

【讨论】：

【解决方案2】：

如果使用状态完整的模型，则使用监督控制器，并且我们需要视图通过观察者/可观察机制立即与其同步，在这种情况下，我们可能希望减少可测试性并允许视图之间的直接通信和模型。

请注意，Presenter（直接）和 Model（通过事件）都会提示 View 更新其显示。在大多数情况下，视图会响应模型状态的简单变化并自行更新，当涉及更复杂的逻辑时——Presenter 负责根据应用程序规则更改视图。

以您为例，您的 UserControl1 将通过演示者将数据发送到模型，然后模型将通知所有已注册的视图更改（将它们发送到模型以进行相应的更新）。

希望对您有所帮助。

【讨论】：

【解决方案3】：

我认为根据您的说法，您最好考虑让一名演示者专门协调（和监督）特定演示所需的内容（即“收集客户信息”）。然后考虑在构建时将模型（或如果有足够复杂性的模型的外观）传递给该 Presenter。

如果用户控件有一个本身与模型紧密耦合的演示器（文本框在表面上听起来不像），那么您可以将该模型传递给该演示器，但我不会传递它进入视图界面。

我现在需要更多地了解您所说的用户控件，以便有机会帮助您构建它们的演示文稿。

我不知道有哪个示例可以确定您开始充实的场景，但我会关注 Fowler 网站上的不同 mvp 示例，并查看 Jeremy Miller 的 Build Your Own Cab 系列。两者都会有点令人沮丧，因为两者都不会快速解决您的问题，但两者都会让您深入了解这个广泛主题的各个方面。

希望对您有所帮助！浆果

【讨论】：

【解决方案4】：

我们在这个主题上遇到了一些严重的问题。我们首先假设第一个视图负责创建和配置第二个视图，第一个演示者负责创建和配置第二个视图。由于许多原因，该解决方案很糟糕。首先，第二个视图由其他两个对象（第一个视图和第二个演示者）配置。第二个缺点是将视图绑定在一起并且对视图具有逻辑责任。

我们一直在寻找解决方案，并决定我们需要将此绑定松散并在演示器中执行。因此，我们创建了与给定 id（字符串或 guid）匹配的视图和演示者的工厂板条箱对。当用户在视图上执行某些操作时，此呼叫将转发给演示者，并决定应该显示哪对。

【讨论】：