What benefits does IOC provide over soft-coding?

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_c开发者_运维技巧ampaign=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

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.

For that particular application of IoC, it means you don't have to know the string keys everywhere you use the settings, just where you read them.

It also means the Foo class can be given application settings that came from somewhere other than the configuration file. This is useful for unit-testing, or for one-off instances of Foo which need settings other than those defined in the configuration file.

A good question to ask might be: should Foo know how to read configuration settings and use them?

In that particular article, Patrick decouples the Foo class' direct dependency on the config file, it's structure etc. By implementing an interface to those settings and then passing them from the outside to the Foo class, Foo gets what it needs, runs as it should but is no longer dependent on the config file only. Foo doesn't care where the settings come from.

These concepts are called decoupling and dependency injection and help to create much more manageable, and per Patrick's example, more testable code.

IoC gives you truly independent reusable components, rather than just a configurable monolithic system. Monolithic systems are harder to maintain because everything is interdependent. Componentized systems are easier to reason about, test and change because you can use each part in isolation.

Inversion of control means that individual components only access each other through abstractions and have no say in how they are wired together. If you read about components in the UML spec (superstructure specification Chapter 8), then it is obvious that the concepts of IoC and "component" must always go hand in hand:

An important aspect of component-based development is the reuse of previously constructed components. A component can always be considered an autonomous unit within a system or subsystem. It has one or more provided and/or required interfaces (potentially exposed via ports), and its internals are hidden and inaccessible other than as provided by its interfaces. Although it may be dependent on other elements in terms of interfaces that are required, a component is encapsulated and its dependencies are designed such that it can be treated as independently as possible. As a result, components and subsystems can be flexibly reused and replaced by connecting (“wiring”) them together via their provided and required interfaces. The aspects of autonomy and reuse also extend to components at deployment time. The artifacts that implement component are intended to be capable of being deployed and re-deployed independently, for instance to update an existing system.