Question

Microsoft的Unity依赖注入框架可以通过代码或应用程序配置文件（app.config）进行配置。

代码示例：

IUnityContainer container = new UnityContainer()
    .RegisterType<IInterface, ConcreteImplementation>();

配置示例：

<unity>
    <containers>
        <container>
            <types>
                <type type="IInterface, MyAssembly"
                      mapTo="ConcreteImplementation, MyAssembly" />

每种方法有哪些优点/缺点？我可以想到“用户可以轻松配置您的应用程序”的明显优势，以及明显的缺点“用户可以轻松破解您的应用程序”，但是有什么不太明显的吗？

Answer 1

XML配置实际上只对单个事物有益：后期绑定。使用XML配置，您可以更改应用程序的组成方式，而无需重新编译整个应用程序。这与支持一定程度用户配置的 ISV应用程序特别相关。 ISV可以发送具有默认行为的已编译应用程序，但允许客户/用户通过更改配置来更改部分行为。

然而， XML配置是脆弱且冗长的。从开发人员的角度来看，使用它只是一种痛苦。

重命名类型或程序集时，配置会中断。
您必须手动将相应的.dll复制到输出目录（或者让构建脚本执行此操作）。
整体冗长使其难以使用。
工具支持弱于强类型代码。

根据经验，更喜欢代码配置。但是，您可以将Code as Configuration与XML配置进行匹配，因此如果您有一些应该延迟绑定的依赖项，则可以使用XML配置。

Answer 2

通过代码进行配置的一个显着缺点是代码需要对程序集的引用。这意味着我必须在项目中添加项目或DLL引用，以便编译代码。

依赖注入应该删除组件之间的依赖关系。通过代码初始化通过要求项目或DLL引用来重新引入依赖项。 xml配置文件可以引用任何程序集。

如果我基于接口创建新实现，我可以通过添加已编译的DLL并更新xml配置文件将新实现集成到现有应用程序中。如果我通过代码进行配置，我必须重新编译应用程序以替换实现。

Answer 3

问题已经回答，但我想总结一下我的经验：

同时使用。我将代码配置隐藏到扩展中，当我有几个标准配置（通常 - 因为我使用IoC）然后我有几个扩展，共享主配置。

我正在将XML配置用于非标准任务，例如性能调优（在重新编译需要很长时间的环境中）。

是应该在代码或配置文件中配置Unity？

3 个答案: