Question

Take the following article for example:

http://weblogs.asp.net/psteele/archive/2009/11/23/use-dependency-injection-to-simplify-application-settings.aspx?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+dotnetmvp+%28Patrick+Steele%27s+.NET+Blog%29

I don’t see what benefit there is from the IOC approach as opposed to the traditional soft-coding approach. Can someone tell me what I am missing?

Thanks

Answer 1

The article itself pretty much answers your question:

During production, dependency injection takes over and automatically gives me my AppConfigSettings instance. For testing, I generate a mock IApplicationSettings.

Generally speaking, design patterns, practices and approaches (IoC is not much a pattern) try to help you at least one thing: minimize coupling and maxmize cohesion. When you’re directly using ConfigurationManager and all that (Convert.ToBoolean, etc) you are:

• Coupling your code to ConfigurationManager (bad for testing and reuse)
• Coupling your code to the configuration file itself (there’s no other way to configure your class other than through .config file; bad for testing and reuse as well)
• Mixing responsibilities (reading and parsing configuration settings; violates SRP)

Granted, using IoC only for reading configuration settings is an overkill, but surely this post deals only with a small part of a much bigger picture.