我一直在尝试使用经常提到的MVVM模式，并且在某些情况下很难定义清晰的边界。在我的应用程序中，我有一个对话框，允许我创建一个控制器的连接。对话框有一个ViewModel类，足够简单。但是，该对话框还托管一个附加控件（由ContentTemplateSelector选择），具体取决于被连接的特定类型的控制器。此控件具有其自己的ViewModel。
我遇到的问题是当我按 OK 关闭对话框时，我需要实际上创建请求的连接，这需要在内部 Controller-specific ViewModel 类中捕获的信息。简单地让所有Controller-specific ViewModel类实现构造连接的公共接口似乎是很诱人的，但是内部ViewModel真的应该负责这个构造吗？
我的一般问题是：是否有任何通常接受的设计模式来管理ViewModel之间的交互，特别是在“父”VM需要帮助“子”VM才能知道要做什么的情况下？
编辑：
我想出了一个比我最初想象的更干净的设计，但我仍然不确定这是否是正确的方法。我有一些后端服务，允许 ContentTemplateSelector 查看 Controller 实例并凭空找到一个控件以显示连接生成器。困扰我的是，我的顶级ViewModel将不得不查看生成的控件的 DataContext 并将其转换为适当的接口，这似乎是个坏主意（为什么 View 的 DataContext 与创建连接有任何关系？）
我最终得到了类似以下内容的东西（简化）：
我遇到的问题是当我按 OK 关闭对话框时，我需要实际上创建请求的连接，这需要在内部 Controller-specific ViewModel 类中捕获的信息。简单地让所有Controller-specific 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 执行建立这一过程仍然让我有些困扰。
如果有方法可以进一步简化此过程，欢迎分享更多想法。对于 ViewModel 应该拥有多少责任，我仍然不太清楚。