我一直在试验经常提到的 MVVM 模式,但在某些情况下我一直很难定义明确的界限。在我的应用程序中,我有一个对话框,允许我创建到 Controller 的连接。对话框有一个 ViewModel 类,这很简单。但是,该对话框还包含一个附加控件(由 ContentTemplateSelector
选择),该控件因所连接的特定类型的 Controller 而异。此控件有自己的 ViewModel。
我遇到的问题是,当我按确定关闭对话框时,我需要实际创建请求的连接,这需要在特定于 Controller 的内部 ViewModel 类中捕获的信息。简单地让所有特定于 Controller 的 ViewModel 类实现构造连接的公共(public)接口(interface)是很诱人的,但是内部 ViewModel 真的应该负责这种构造吗?
我的一般问题是:对于 ViewModel 应该如何相互交互,是否有任何普遍接受的设计模式,特别是当“父”VM 需要“子”VM 的帮助才能知道该做什么时?
编辑:
我确实想出了一个比我原先想象的更简洁的设计,但我仍然不确定这样做是否是“正确”的方法。我有一些后端服务允许 ContentTemplateSelector 查看 Controller 实例并伪神奇地找到要为连接构建器显示的控件。让我烦恼的是,我的顶级 ViewModel 必须查看生成的控件的 DataContext
并将其转换为适当的接口(interface),这似乎是个坏主意(为什么 View 的DataContext
与创建连接有什么关系?)
我结束了这样的事情(简化):
public interface IController
{
IControllerConnectionBuilder CreateConnectionBuilder();
}
public interface IControllerConnectionBuilder
{
ControllerConnection BuildConnection();
}
我有我的内部 ViewModel 类实现 IControllerConnectionBuilder
并且 Controller 返回内部 ViewModel。然后顶层 ViewModel 可视化此 IControllerConnectionBuilder
(通过伪魔法机制)。它仍然让我有点困扰,这是我的内部 ViewModel 执行构建,但至少现在我的顶级 ViewModel 不必知道肮脏的细节(它甚至不知道或关心可视化控件正在使用 View 模型)。
如果有办法进一步清理它,我欢迎提出其他想法。我仍然不清楚 ViewModel 可以承担多少责任。
最佳答案
一个适用于 View 模型之间交互的选项是直接绑定(bind)到 observer位于 View 模型类之间的类。
关于c# - MVVM:如何处理嵌套 ViewModel 之间的交互?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/2576536/