问题标签 [mediator]

将中介模式用于琐碎的消息（显示图像查看器窗口等）是一种好的编程习惯吗？

而不仅仅是使用

我在我的程序中经常使用调解器程序，并且想知道有多少是太多了。

问候，
Seb

有人能指出两者之间的主要区别吗？

似乎，至少在概念上，两者是非常密切相关的。如果我冒险猜测，我会说发布/订阅方法是中介模式的一个子集（因为中介不一定必须以发布/订阅方式使用，但后者似乎需要一种中介目的）。是不是离它很近？

我需要构建一个非常简单的向导，它将通过三个步骤将文本文件导入应用程序，并且我需要使用中介模式。我只是想知道是否有一些示例应用程序或一些教程或文档。我试图在互联网上搜索一些，但没有找到任何示例。

两个 ViewModel 之间通信的常用方法是：MVVM- View Model-View Model Communications

中介者模式或信使类。但是一个窗口中有 6 个 ViewModel 呢？

1. 新学校类用户控件
2. 新瞳孔用户控件
3. SchoolclassListUserControl
4. 瞳孔列表用户控件
5. 学生详细信息用户控件
6. AdministrationButtonBarUserControl（具有执行命令的按钮）

所有这些都在一个窗口中。“你”现在真的告诉我我必须为这 6 个视图及其 Viewodels 设置一个 Messenger 吗？那将是可怕的...

一个窗口中有 6 个用户控件，即使是大型企业应用程序在一个窗口中也没有更多的用户控件，那么在这种情况下，什么是公认的/最佳实践？

我会对具有大型 mvvm 应用程序经验的人的意见感兴趣:)

其中一些 UserControl+ViewModel 我想在我的应用程序的其他地方重用。因此，将所有内容放在一个 UserControl 中并不是我真正想要的。

更新：对于盲目的meise ;-)

@blindmeise

这个 ViewModel 实际上是一个 DataGrid 的数据模板。期间是行。每行都有一个名为 Documents 的列。我有一个 PeriodListViewModel 1 : N DocumentListViewModel。

DocumentListViewModel 使用包含 ListBox 的 UserControl 进行数据模板化，并在一些按钮下方添加/删除/保存/打开等...

DocumentListViewModel 具有在“LessonController”中执行的命令和操作委托，因此对 Document 的每个操作（如 add、del 等）都可以在 LessonController 中声明的 SelectedPeriodViewModel 上完成。

上面的代码只是在用户更改日期选择器中的日期时从数据库中加载新数据。

您是否需要更多代码，或者您对我的方法有何看法？我渴望学习，我为每一个批评者感到高兴！

我有一个 CustomerListViewModel 和一个 OrderListViewModel。在后者中，我选择一个订单来删除它，或者我创建一个新订单。在这两种情况下，我的 CustomerListViewModel 和 Messenger 都必须注册到 IOrder 类型：

我的 ButtonBar 上有一个 DateNavigatorViewModel + DateNavigatorView。

以下是交换的 2 个视图：DailyView 和 WeeklyView。每个视图都有一个 DailyViewModel 和 WeeklyViewModel。

在我的 DateNavigatorViewModel 我有messenger.Send(SelectedDate);

在我的 DailyViewModel 和 WeeklyViewModel 中，每个都在构造函数中注册：

猜猜当我选择一个日期时会发生什么......

我正在使用 MVVM Light 工具包。

如何解决从数据库中获取 2 倍数据的问题？

我不喜欢我使用的 Messenger（mvvm light 工具包），当我注册到 DateTime 并发送一些东西时，我的应用程序的其他部分也会获取数据时间数据，因为它们注册为“DateTime”类型。

为了防止这种情况发生，我必须始终创建自定义对象并包装我的日期时间值。那是愚蠢的。

你如何解决这个问题？

我正在使用 MVVM 模式开发 WPF 应用程序。我正在使用 MVVM Light 库，并且我也在尝试使用依赖注入器（我正在考虑 Ninject 和 Unity）。

我已经阅读了很多博客文章，我对让我的班级相互交流的“正确”方式感到很困惑。特别是，我不知道什么时候使用依赖注入，什么时候依赖中介模式。

让我们考虑一个例子。我有一个 ViewModel，我们称之为 DataViewModel，以及提供某种数据的 Data 类。他们之间如何更好地沟通：

A. 使用 IData 接口注入对 DataViewModel 的依赖？这样 Data 就不必依赖 Messenger，但如果 Data 发生变化，它必须提供一个事件，并且 ViewModel 必须订阅它。

B. 依赖中介者模式（在 MVVM Light as Messenger 中实现），在 Model 和 ViewModel 之间发送消息？这种方式根本不需要使用依赖注入，因为整个通信将基于消息。

此外，我的 ViewModel 是否应该在其他 ViewModel 上注入依赖关系，还是仅仅依赖 Messenger 会更好？如果是第一个，是否有必要为每个 ViewModel 定义一个单独的接口？我认为为每个 VM 定义一个接口将是一项额外的工作，但也许值得。

WPF/MVVM alpha 极客说：

1 个视图有 1 个视图模型。有时 Multiple Views 有 1 个 ViewModel （使用Wizard）。

如果您考虑我的图像，您会看到 6 个彩色视图/用户控件。

在我的应用程序中多次使用黄色、绿色和橙色用户控件。

粉色、蓝色和红色的用户控件只使用一次。

问题：

1.我也应该让它们成为用户控件吗？如果是，为什么我不重复使用它们。

2.假设那些是 6 个 UserControl，它们应该共享同一个 ViewModel 吗？或者每个视图应该有自己的视图模型？

A.) 在绿色中创建 Classcode 将类代码发送到 YELLOW

B.) 在黄色中选择班级代码 用蓝色更改当前学生

C.) 在蓝色中选择当前学生 在红色中更改学生详细信息 在橙色中更改学生文档

D.) 在 PINK 中创建瞳孔 将瞳孔发送到 BLUE

E.)... 更多

这是要走的路吗，使用 Messenger 类围绕数据触发以使关系保持最新？

对我来说有一个重大缺陷：

我创建了一个 PupilViewModel，但我不知道在 NewPupilViewModel(PINK) 中 YELLOW UserControl 中是否存在 SchoolclassCodeViewModel，因此我可以将我的新 PupilViewModel 添加到 BLUE UserControl。

SchoolclassCodeViewModel 1：N PupilViewModel。

3.你会如何解决这个问题？

我试图弄清楚在某种情况下要遵循哪种模式。我有一个网络应用程序，它由几个以某种方式相互交互的主要小部件组成。小部件遵循模块模式。

让代码说话：

如您所见，我在这里有紧密的耦合。众所周知，紧耦合是邪恶的。（除非你找到了唯一的一个！;-)）

我知道通过遵循发布-订阅/自定义事件模式可以实现很多解耦。但这更适合 A 开始某事而 B 可以做出反应的情况。但我有一种情况，A 独立启动某事，但需要检查 B 的某个状态才能继续。

当我努力实现可维护性时，我正在寻找摆脱这个地狱的方法。

我首先想到的是中介模式。

但是，我的代码仍然是这样的：

这样稍微好一点，因为 Widget 不直接通信，而是通过中介间接通信。

但是，我仍然觉得我做错了，必须有更好的方法来实现小部件之间的解耦。

编辑

让我总结一下到目前为止的事情！

总的来说，我确实喜欢分离视图的 MVC 方法！但是，将此示例更像是复杂的模块。从视觉上看，这些不一定是“盒子”。这种方式更容易描述。

另一个给定的事实应该是，A独立启动一个动作，然后需要检查某个状态。它无法订阅 B 的状态更改并提供操作或不提供。它必须像 A独立启动它，然后需要检查某个状态。将此视为需要 B 进行的一些复杂操作。

所以我想出了一个混合自定义事件/回调/调解器的方法，我真的很喜欢它的一些东西。

1.) 一个模块不知道任何其他模块
2.) 一个模块也不知道中介者
3.) 依赖于某些外部状态的模块只知道它依赖于某些外部状态 - 不多
4.) 模块真的不在乎谁将提供这个特定状态
5.) 模块可以确定是否已经提供了特定状态
6.) 请求管道是直的。换句话说，模块是此操作的启动器。它不只是订阅状态更改事件（请记住 A 开始操作，然后需要来自 B（或某处）的状态

我在这里发布了一些示例代码，还提供了一个 jsFiddle：http: //jsfiddle.net/YnFqm/