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

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.但是,您可以将Code as Configuration与XML配置相匹配,因此如果您有一些应该延迟绑定的依赖项,则可以使用XML配置.

Answer 2

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

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

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