2

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

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

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

假设我有这样的用户界面: alt text http://img12.imageshack.us/img12/2683/layoutcroped.jpg

对不起,狡猾的 UI 模型。基本上每个用户控件都有自己的演示者和模式层对象。

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

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

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

编辑: 我已经制定了两种不同的方法,我认为我可以这样做:

我认为 Ex1 更好,因为它仍然让主持人负责。去做他们想做的事。

你怎么看?

谢谢。

4

4 回答 4

1

我将采用的方法是面向事件的发布/订阅方法。

模式是这样的:

  1. 用户在第一个视图上单击“编辑”按钮会触发一个带有单个参数(在本例中为文本框的 ID、值)的事件(您可以将其称为命令)。比如说,将事件称为“EditRequested”。这是事件的“发布”,告诉任何想知道这已经发生的人和细节。实际的发布可能在控制器/演示者中完成。

  2. 第二个视图的控制器/演示者侦听上述事件,并在事件触发时采取相应的行动,加载数据并使用事件参数 (ID) 切换到编辑模式。这是模式的“订阅”部分。

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

于 2009-07-26T15:24:09.887 回答
1

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

监督控制器

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

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

希望有帮助。

于 2009-07-27T16:23:22.530 回答
0

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

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

于 2009-07-09T07:00:31.103 回答
0

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

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

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

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

希望能帮助到你!绿柱石

于 2009-07-09T04:30:18.657 回答