【发布时间】：2011-02-04 07:32:21
【问题描述】：
我一直在尝试经常提到的 MVVM 模式，并且在某些情况下我很难定义清晰的边界。在我的应用程序中，我有一个对话框，允许我创建与控制器的连接。对话框有一个 ViewModel 类，很简单。但是，该对话框还包含一个附加控件（由ContentTemplateSelector 选择），这取决于所连接的控制器的特定类型。该控件有自己的 ViewModel。
我遇到的问题是，当我按 OK 关闭对话框时，我需要实际创建请求的连接，这需要在内部特定于 Controller 的 ViewModel 类中捕获信息。简单地让所有特定于 Controller 的 ViewModel 类实现一个构造连接的通用接口是很诱人的，但是内部 ViewModel 真的应该负责这个构造吗？
我的一般问题是：对于 ViewModel 应该如何相互交互，是否有任何普遍接受的设计模式，尤其是当“父”VM 需要“子”VM 的帮助才能知道该做什么时？
编辑：
我确实提出了一个比我最初想的更简洁的设计，但我仍然不确定这是否是“正确”的做法。我有一些后端服务允许 ContentTemplateSelector 查看 Controller 实例并伪神奇地找到要为连接构建器显示的控件。让我烦恼的是，我的顶级 ViewModel 必须查看生成的控件的 DataContext 并将其转换为适当的界面，这似乎是个坏主意（为什么 View 的 DataContext 有任何东西与创建连接有关吗？）
我最终得到了这样的东西（简化）：
public interface IController
{
IControllerConnectionBuilder CreateConnectionBuilder();
}
public interface IControllerConnectionBuilder
{
ControllerConnection BuildConnection();
}
我有我的内部 ViewModel 类实现 IControllerConnectionBuilder 并且控制器返回内部 ViewModel。然后顶层 ViewModel 将这个IControllerConnectionBuilder 可视化（通过伪魔法机制）。它仍然让我有点困扰，它是我的内部 ViewModel 执行构建，但至少现在我的顶级 ViewModel 不必知道肮脏的细节（它甚至不知道或关心可视化控件正在使用视图模型）。
如果有办法进一步清理这个问题，我欢迎提出其他想法。我仍然不清楚 ViewModel 应该承担多少责任。
【问题讨论】：
-
我们在工作中经常问自己这类问题。你这个问题的措辞很好，所以我希望你能在这里得到一些好的反馈。
-
谢天谢地，这是一个宠物项目，所以我有幸探索不同的设计。我的商店没有采用 WPF 或 MVVM，因为早期阶段的开销和笨拙对于我们当前的日程安排是不可接受的。我坚信这是一项技术，一旦我们了解如何使用它，它就会在生产力方面带来巨大的收益，但它的视角发生了如此大的转变，以至于很难知道在设计中应该在哪里划清界限。
标签： c# architecture mvvm