Unity应该在代码中配置还是在配置文件中配置？
Microsoft 的 Unity 依赖注入框架可以通过代码或应用程序配置文件 (app.config) 进行配置。
代码示例：
IUnityContainer container = new UnityContainer()
.RegisterType<IInterface, ConcreteImplementation>();
配置示例：
<unity>
<containers>
<container>
<types>
<type type="IInterface, MyAssembly"
mapTo="ConcreteImplementation, MyAssembly" />
每种方法的优点/缺点是什么？我可以想到明显的优点“用户可以轻松配置您的应用程序”，以及明显的缺点“用户可以轻松破坏您的应用程序”，但是还有什么不那么明显的吗？
Microsoft's Unity dependency injection framework can be configured either through code or through the applications configuration file (app.config).
Code example:
IUnityContainer container = new UnityContainer()
.RegisterType<IInterface, ConcreteImplementation>();
Configuration example:
<unity>
<containers>
<container>
<types>
<type type="IInterface, MyAssembly"
mapTo="ConcreteImplementation, MyAssembly" />
What are the advantages/disadvantages to each approach? I can think of the obvious advantage "Users can easily configure your application", and the obvious disadvantage "Users can easily break your application", but is there anything less obvious?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
XML 配置实际上只对一件事情有好处：后期绑定。通过 XML 配置，您可以更改应用程序的组成方式，而无需重新编译整个应用程序。这对于支持一定程度用户配置的ISV 应用程序尤其重要。 ISV 可以发布具有默认行为的已编译应用程序，但允许客户/用户通过更改配置来更改部分行为。
然而，XML 配置很脆弱且冗长。从开发人员的角度来看，这只是一种痛苦的工作。
根据经验，更喜欢将代码作为配置。但是，您可以将代码作为配置与 XML 配置相匹配，因此，如果您有一些应该后期绑定的依赖项，则可以对它们使用 XML 配置。
XML configuration is really only beneficial for a single thing: Late Binding. With XML configuration you can change how your application is composed without recompiling the entire application. This is particularly relevant for ISV applications that support a degree of user configuration. ISVs can ship a compiled application with default behavior, but enable customers/users to change parts of the behavior by changing the configuration.
However, XML configuration is brittle and verbose. From a developer's viewpoint, it's just a pain to work with.
As a rule of thumb, prefer Code as Configuration. However, you can match Code as Configuration with XML configuration, so if you have a few dependencies which should be late bound, you can use XML configuration for those.
通过代码进行配置的一个显着缺点是代码需要引用程序集。这意味着我必须在项目中添加项目或 DLL 引用才能编译代码。
依赖注入应该消除组件之间的依赖关系。通过代码进行初始化会通过要求项目或 DLL 引用来重新引入依赖性。 xml 配置文件可以引用任何程序集。
如果我基于接口创建新的实现，我可以通过添加已编译的 DLL 并更新 xml 配置文件，将新的实现集成到现有应用程序中。如果我通过代码进行配置，我必须重新编译应用程序才能替换实现。
One significant disadvantage of configuration via code is the code requires a reference to the assemblies. This means I have to add project or DLL references in the project in order for the code to compile.
Dependency injection is supposed to remove dependencies between components. Initialization via code reintroduces the dependency by requiring project or DLL references. The xml configuration file can reference any assembly.
If I create a new implementation based on an interface I can integrate the new implementation into an existing application by adding the compiled DLL and updating the xml configuration file. If I do the configuration via code, I have to recompile the application in order to replace an implementation.
问题已经得到解答，但我想总结一下我的经验：
两者都使用。
我将代码配置隐藏到扩展中，当我有几个标准配置（通常是因为我使用 IoC）时，我有几个共享主配置的扩展。
我使用 XML 配置来执行非标准任务，例如性能调整（在重新编译需要很长时间的环境中）。
Question is already answered but I want to summarize my experience:
Use both.
I'm hiding Code Configuration into Extension, when I have several standard configurations (usually - that because I use IoC) then I have several extensions, that share main configuration.
I'm using XML configuration for non standard tasks like performance tuning (in the environment where the recompilation take a long time).