Question

我是C＃/。Net / Prism / WPF / DevExpress的新手，并且开始从事我公司的一个大型项目。当我在项目中开始得有点晚时，已经产生了很多代码，并且我经常偶然发现这样的代码：

public class AboutWindowViewModel : BindableBase
{
  public AboutWindowViewModel(IUnityContainer container)
  {
    ...

我在这里发现“特殊”之处在于容器中视图模型的依赖性。在我当前正在查看的代码库中，它似乎是“模式”。每个类都在IUnityContainer中获得依赖关系，然后使用例如

手动解决依赖关系。

container.ResolveEx<...>(...);

我习惯于使用其他语言的DI框架，因此该示例对我来说只是个废话，因为它违背了DI框架的定义及其要解决的问题。例如，我试图编写一些代码来测试其中一种视图模型，结果证明这是一场噩梦。

现在，我向公司的开发人员解决了这个问题，他们回答了我以下问题：

Prism recommendation is to resolve services using containers as they are needed.

因此，它们始终使用IUnityContainer.ResolveEx方法来解决它们。

我的问题是：这真的是使用Prism构建软件的推荐方法吗？？？如果没有，您知道我在哪里可以找到示例清楚地说明了这一点的文档吗？

Answer 1

这真的是使用Prism构建软件的推荐方法吗？

一点也不，因为它是anti-pattern。

主要建议是根据需要使用容器来解决服务。

不只是Prism，而是更普遍的建议是让容器解决依赖关系。当然，可以通过手动调用Resolve来完成此操作，但是这样做会破坏依赖注入带来的所有好处。

相反，您希望将依赖项作为构造函数参数列出，并让容器填充它们。除了非常入口点（“解析根”）之外，您的代码不需要依赖于容器。该应用程序只能包含一个解析第一个实例的Resolve语句。

这就是Prism发挥作用的地方：在PrismApplication.RegisterTypes和IModule.RegisterTypes中，您可以配置容器。您告诉它哪种类型应该实现哪种接口。稍后，当需要视图模型时，Prism（确切地说是ViewModelLocator）使用容器来解析视图模型，从而解决所有依赖关系。没有理由让任何类都依赖于容器，事实上，Prism最初并没有为IContainerRegistry注册任何东西。

请记住，容器不仅可以注入单例服务，还可以注入临时实例或工厂。而且，如果您需要参数化的工厂，则始终可以手动创建和注册复杂的工厂。

在旁注中，我个人会犹豫要为具有这样的代码库的客户工作，因为这显然证明了他们的开发人员不知道自己在做什么。

我的视图模型中的Unity容器注入

1 个答案: