System.ComponentModel

With much of the Java and OO world discussing Inversion of Control (IoC) patterns, also dubbed "dependency injection" by Martin Fowler, its worth remembering that the .NET Framework has always included a "service locator" pattern which allows a component to access shared "services".

It can be used to support a pattern which provides a mechanism by which one can loosely-couple components - i.e. eliminate hard coded dependencies between objects.  [For those lightweight container aficionados here, .NET's implementation provides for Type 1 (interface) IoC injection of a "Service Locator" into each .NET Component]

It's widely used in the Framework and in tools like Microsoft Visual Studio.  For example, it underpins the Windows Forms Designer architecture, and it is the mechanism through which Windows Forms Controls inherit aspects of the underlying Form.  You could use it to share say a particular ToolBar across Forms, but it goes much further than that - really to the heart of OO and how one can wire together objects without introducing hard-wired dependencies.

One can write loosely-coupled code like that shown below, which "injects" a particular implementation (in this case "SlowDriver") into "myCar".

using System.ComponentModel;

Container myContainer = new Container();
myContainer.Add(new FastDriver(), "fast");
myContainer.Add(new SlowDriver(), "slow");

IDriver driver = (IDriver)myContainer.Components["slow"];
// error checking removed for brevity

Car myCar = new Car(driver);
Console.WriteLine("Maximum speed is " + myCar.Speed);

Where is it?  It's defined in the System.ComponentModel namespace.  Like the Spring.NET framework, one could use System.ComponentModel to create a context-based pluggable architecture as an alternative to the .NET 2.0 Provider Model.

Unfortunately though, is neither widely known or used, despite the recent big interest in lightweight containers, largely because many interfaces in the namespace don't have default implementations, and because IoC concepts require a good understanding of underlying OO concepts.

The whole area is important for the future because such patterns allow for the separation of configuration from use, something that is really important in terms of Microsoft's future MDA through tools architectural strategy.