我们开始在 WPF 中采用 MVVM 模式,到目前为止,我们已经将 ViewModel 从 View 中分离出来,并且我们已经创建了Command
类。但在所有情况下,我们首先初始化 View 并在代码隐藏中生成 ViewModel。我想它并没有探索 MVVM 的全部好处。例如,当一个新的 UI 组件应该由 a 生成时Command
,我认为Command
ViewModel 和 View 混合在一起,因为它需要知道两者并创建它们。没有明确的区分。
现在我有另一个问题,我认为也可能与这个问题有关:在 WPF 应用程序中,我们需要托管一个 WCF 服务,该服务从同一台机器上的不同应用程序接收请求,并初始化相应的 WPF 控件。由于我们在非 UI 线程中托管服务(我们不希望将主机放在 a 的代码隐藏中UserControl
),因此UserControl
无法在托管线程中生成结果。所以我想现在我必须初始化 ViewModel,然后尝试解析相应的 View。
在使用 MEF 作为依赖注入和使用 EventAggregator 来通知新 ViewModel 的生成之前,我有一些经验。但既然它会给我们当前的项目带来很多变化,我想知道,我还有其他选择来解决视图吗?
到目前为止,我们的 UI 仍然非常简单,但从长远来看,我们将需要创建一个复杂的 UI。但进一步的问题是:是否应该始终使用 MEF/Unity 以便为复杂的 UI 采用 MVVM 模式?现在我觉得为了分离ViewModel和View,它们是必须的。我对么?
更新:
一些答案指向我,我可以简单地拥有一个 DataTemplate,它告诉 XAML 如何呈现我的 ViewModel。比如我可以在一个ContentControl
主UserControl中声明一个(我叫它UC_Host),它会根据ViewModel的类型来选择View,并且它的DataContextContentControl
是绑定到我生成的ViewModel上的。据我了解,这是可行的,例如,如果我的 UC_Host 始终存在并且只有一个 UC_Host 可用于托管 UC。
但是在我们的项目中,我们实际上是想在 new 中显示生成的 UC Window
,并且数量Window
不受限制(WPF 中仍然没有 MDI,多窗口布局是我们目前对某些任务的解决方案)。这意味着我们没有在 new 之上占主导地位的 uniqie UC_Host,Windows
因此从那里绑定到 ViewModel 也不容易。
这就是为什么我正在寻找让我的 MainView 解析视图的解决方案(因为只有在 UI 线程中它才能生成 UIElement 并Window
可能在其代码隐藏中生成一个新元素)。我想直接数据绑定是不可能的