Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>Configuring your DI container completely through XML is error prone, verbose, and just too painful. The XML configuration possibilities are always a subset of what you can do with code based configuration; code is always more expressive.</p> <p>Sometimes though your DI configuration depends on deploy-time configurations, but since the number of knobs you need are often fairly small, using a configuration flag is often a much better approach than polluting your configuration file with fully qualified type names.</p> <p>Or let me put it differently, when you have large amounts of your DI configuration placed in your configuration file because your might want to change them at deploy time, please think again. Many of the changes need testing (by a developer) anyway, so there is no way you want someone from your operations team to fiddle around with that. And when you need a developer to look at it and verify it, what's the advantage of not having to recompile the project? Is this actually any quicker? A developer would still have to start the application anyway.</p> <p>It is a false sense of flexibility and in fact a poor interface design (xml is the interface for your maintenance and operations department). BTW, are you the person that needs to document how the configuration file should be changed? Instead of describing the list of fully qualified type names that are valid somewhere in the middle of the xml file, wouldn't it be much easier of all you have to write is "place 'false' in this field to disable ..."?</p> <p>Here is an example of how to use a configuration switch:</p> <pre class="lang-cs prettyprint-override"><code>bool detectFraught = ConfigurationManager.AppSettings["DetectFraud"] != "false"; container.Register( Component.For(typeof(IFraughtDetector)).ImplementedBy( detectFraught ? typeof(RealDectector) : typeof(FakeDetector)); </code></pre> <p>See how the configuration switch is now simply a boolean flag. This makes the configuration file much more maintainable, since the configuration is now a simple boolean switch instead of a complete type name (that can be misspelled).</p> <p>Of course doing the <code>["DetectFraud"] != "false"</code> isn't that nice by itself, but this can simply be solved by creating a strongly-typed configuration helper.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload