在使用Prism时，在视图中注入vm与在XAML中定义vm的优势是什么?

本文关键字：vm 定义 是什么 XAML 注入 Prism 视图 与在 | 更新日期: 2023-09-27 18:13:19

我通常在XAML中直接定义我的视图模型，如下所示:

<Window.DataContext>
    <vm:MyViewModel />
</Window.DataContext>

否则，当ViewModel有构造函数参数时，使用ObjectDataProvider。

在Prism 5的官方pdf文档中，他们在代码背后定义了它，并使用MEF/Unity注入视图模型，如下所示:

[Export] 
public partial class Shell : Window 
{ 
    public Shell() { InitializeComponent(); } 
    [Import] 
    ShellViewModel ViewModel
    {
        set { this.DataContext = value; } 
    }
}

我个人将DI与MEF一起使用，但在这种特殊情况下，我真的没有看到注入VM的任何优势，并认为这是过度使用DI。
(假设:我没有为GUI编写任何庞大的单元测试，它模仿了整个ViewModel，因为我的单元测试依赖于服务层。即使在这种情况下，我也可以在测试用例中动态地切换DataContext)。
但也许我错过了什么。

那么，这两种方法的优缺点是什么?

在使用Prism时，在视图中注入vm与在XAML中定义vm的优势是什么?

有很多问题有你的视图负责创建你的ViewModels，但我将只使用一个作为一个例子;依赖关系管理。假设您定义了一个VM:

public class MyViewModel
{
    public MyViewModel() { }
}

让我们假设在XAML中创建了视图:

<Window.DataContext>
     <local:MyViewModel />
</Window.DataContext>

现在，当您的VM需要服务或依赖项时，您该怎么做?

public class MyViewModel
{
    public MyViewModel(IMyService myservice) { }
}

更糟糕的是，如果该服务有自己的依赖项怎么办?

现在在XAML中定义这个显然是不可能的。如果在代码中定义DataContext，就会遇到与XAML类似的问题;依赖关系管理。如果您已经注入了ViewModel，那么您就不必担心ViewModel需要哪些依赖项，也不必修改代码以适应添加到VM函数中的新依赖项。这样就行了。当您的vm处于不同的程序集并跨多个平台共享时，或者当您需要根据构建配置或设备更改依赖项的具体实现时，这尤其有用。

相关文章：