C# winforms的复杂监控控制器示例

很抱歉，如果之前已经问过这个问题，但我找不到任何帮助

我想知道是否有人有使用监控控制器MVP模式创建复杂winforms的好例子。我读过很多例子，但它们都很简单，只涉及一种形式和一种模型

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

假设我有这样的UI：

对不起，这是一个不可靠的UI模型。基本上每个用户控件都有自己的presenter和模态层对象

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

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

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

编辑： 我制定了两个不同的方案，我认为我可以做到这一点：

• 例1

及

• 例2

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

你觉得怎么样

谢谢。

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

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

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

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

希望有帮助！

---

贝里尔

我们在这个问题上遇到了一些严重的问题。我们首先假设第一视图负责创建和配置第二视图，第一演示者负责装箱和配置第二视图。由于许多原因，这个解决方案是不好的。首先，第二个视图由另外两个对象（第一个视图和第二个演示者）配置。第二个缺点是将视图绑定在一起，并对视图承担逻辑责任

---

我们寻找解决方案已经有一段时间了，我们决定需要这个绑定是松散的，并在presenter中执行。所以我们创建了视图和演示者的工厂装箱对，它与给定的id（字符串或guid）匹配。当用户对视图执行某些操作时，此调用将转发给演示者，并决定应显示哪一对

我将采用面向事件的发布/订阅方法来实现这一点

模式是这样的：

用户单击第一个视图上的编辑按钮会触发一个事件（您可以将其称为命令），其中包含一个参数（在本例中为文本框的ID和值）。例如，将事件称为“EditRequested”。这是事件的“发布”，告诉任何想知道这件事已经发生和细节的人。实际发布可能在controller/presenter中完成

第二个视图的控制器/演示者侦听上述事件，当事件触发时，相应地执行操作，加载数据并使用事件参数（ID）切换到编辑模式。这是模式的“订阅”部分

---

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

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

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

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

---

希望这能有所帮助。

这是我第一个例子的一种变体吗？是的，是的。但扩展了抽象层，允许替换第二对的实现。