Should Unity be configured in code or configuration file?

Question

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?

Duplicate: http://stackoverflow.com/questions/2512316/ioc-dependency-injection-please-explain-code-versus-xml — Mark Seemann, Mar 24 '11 at 11:45
Not a duplicate. That question deals with how you can use code-based congfiguration. My question is why - what are the tradeoffs/benefits. — RB., Mar 24 '11 at 12:32

score 32 · Accepted Answer · answered Mar 24 '11 at 13:00

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.

Configuration tends to break when you rename types or assemblies.
You have to manually copy the appropriate .dlls to the output directory (or have a build script do it).
The overall verbosity makes it difficult to work with.
Tool support is weaker than for strongly typed code.

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.

That's good. I instinctively preferred code, and that's a clear explanation of why. We have a couple of web-services that we might want to late-bind, so we'll just have a couple of XML entries. — RB., Mar 24 '11 at 13:33
ISV stands for "Independent Software Vendor." It's also possible to write a simple form that produces/edits such late-bound configurations, at least avoiding user typos. — GregC, Apr 07 '11 at 00:24
For customer specific implementations and IP contained in each, this is the only way i see to be able to "hot swap" that logic out and keep the .dll's out of an inclusive build cycle — hanzolo, Mar 20 '18 at 17:22

score 10 · Answer 2 · answered Nov 14 '11 at 19:37

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.

Removing dependencies is about more than removing 'dll dependencies'. it's about Separation of Concerns and SRP. Being able to change components without compiling is nice, but is far from being that important IMO in the larger scheme of things — Elad Katz, Nov 14 '11 at 22:13

score 2 · Answer 3 · answered Oct 14 '11 at 18:44

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).

Should Unity be configured in code or configuration file?

3 Answers3

Linked