Unity 框架与 Activator.CreateInstance答案

【问题标题】：Unity Framework vs Activator.CreateInstanceUnity 框架与 Activator.CreateInstance
【发布时间】：2012-08-14 01:05:32
【问题描述】：

我希望做一些简单的事情，例如从配置文件中动态地实例化一个类，其中配置文件存储类型名称列表。我想知道我是否应该使用 Unity Framework 或者只是使用 Activator.CreateInstance。主要区别是什么？

我想做的示例：

LIST myList = Config.GetSection... blah blah

foreach(item in in mylist) {
   IPlugIn x = (IPlugIn)Activator.CreateInstance(item.myPlugInTypeFromConfig,myassembly);

   x.Start(); 
}

在我的情况下，我似乎不需要 Unity 框架，只需激活器即可。

【问题讨论】：

如果您只是使用字符串来指定类型，Activator.CreateInstance 将需要第二个字符串来指定类型所在的程序集：msdn.microsoft.com/en-us/library/d133hta4
您还需要将结果转换为 IPlugin。
明白。上面的代码只是psdo代码..
可能重复：stackoverflow.com/questions/11075574/…

标签： c# dependency-injection unity-container

【解决方案1】：

根本区别在于 Unity（或任何 DI 容器）实际上可以管理您的依赖项。 Activator.CreateInstance 只是创建实例。

如果你有一些类型有构造函数参数而一些没有呢？或者你想要设置的属性？容器将向下递归对象图并找出应该将哪些值放入那些构造函数参数或属性中。 Activator.CreateInstance 不这样做。

容器管理对象的生命周期。如果对于某些类型，您总是希望类型 A 具有相同的实例，而 B 的每种类型都需要一个新实例，该怎么办？用容器来做这件事很简单，你必须自己为 Activator.CreateInstance 做。

如果您所做的只是“从不带参数的配置文件中新建此类型列表”，那么您是对的，您不需要容器。一旦你超越了这一点，容器就会为桌子带来更多的力量。

【讨论】：

【解决方案2】：

如果您有许多要使用组件的类，您会希望使用 Unity。在这些情况下，依赖注入发生在构造函数时。

但是，恕我直言，它不是插件架构的存储库。在我看来，您正在做您需要做的事（尽管您需要演员表和程序集名称），但有一个例外。插件架构通常使用 ConfigurationManager 来控制插件的加载。

有关此类架构的真正好文章，您可以阅读 Dobbs 博士的 this article。

【讨论】：