Question

我试图证明使用Unity进行依赖注入以及自定义界面，例如：

public interface IResolver
{
   ITypeA TypeA { get; }
   ITypeB TypeB { get; }
}

public static ResolverFactory
{
   // set by unit tests or Main() method, etc.
   public static IResolver DefaultResolver { get; set; }
}

为什么选择使用像Unity框架这样更复杂的方法？

Answer 1

DI本质上很复杂。在一个简单的场景中应用DI，这通常在教程和示例中完成，乍一看似乎总是有点过分。当应用程序很复杂时，DI才开始支付股息。

如果您有复杂的应用程序，那么添加DI来组成应用程序是有意义的。使用基于约定的配置（大多数DI容器支持开箱即用）可以节省数百或数千行配置代码，并使应用程序更易于维护。您的简单DI容器没有基于约定的配置。

编写自己的DI容器并不是重新发明轮子。车轮非常简单，DI很复杂。编写自己的DI容器更像是重新发明灯泡。为什么要找到一个功能齐全的（实际上是免费的）并将其拧到适当位置的麻烦呢？

此外，你完全忽略了这一点。你发明的是service locator。 DI容器通常不以这种方式使用。大多数DI容器都具有内置的能力，可以自动递归地将依赖关系注入到整个对象图的构造函数中。它们通常用于application composition，而不是服务位置。这是他们的主要目的。

为了让你的简单DI容器以这种方式工作，你需要使用Reflection加载每个类型，分析构造函数并提出一些标准化的方法来选择最好的，然后加载所有的依赖类型（构造函数参数）），以及它们的依赖关系等递归。然后，您必须从对象图的底部开始，并使用Reflection以递归方式调用每种类型的最佳构造函数，以创建每种类型的实例。在创建实例本身之前递归地创建每个实例的依赖关系，直到组成整个对象图。你可能最终还需要重新发明一种做属性注入的方法。只需下载NuGet包并阅读现有DI容器的文档即可避免所有这些工作。

我强烈建议您阅读本书Dependency Injection in .NET。 DI是软件开发中最容易被误解的概念之一，非常值得投资自己详细研究这个主题，而不必在互联网上筛选错误的信息。正确使用DI可以获得许多好处，但不正确的使用通常比完全不使用DI更糟糕。更不用说，本书为您提供了加载的其他原因，为什么世界不需要另一个DI容器实现。

哦，还有最后一件事 - 不要使用Unity。 Unity是最差的DI容器之一，缺少几个重要功能。另一方面，Autofac，Ninject，StructureMap和Castle Windsor都是不错的选择。

Answer 2

如果你正在寻求实现自己的DI实现，我建议你先看看Unity，Autofac，StructureMap或Ninject等。

为什么呢？简单地说：不要重新发明轮子。 DI库已经编写并且非常灵活。它们还有各种用于ASP.NET MVC的钩子。当您可以利用现有的库时，编写自己的工作就会做得更多。如果你真的需要你自己的实现，那就去吧，但是我认为那里的众多DI库之一将满足你的需求。

Unity vs自定义依赖注入？

2 个答案: