MSDN Magazine - March 2008 - (Page 60)

dictionary to store mapping information between interfaces and objects implementing those interfaces. We need a way to initially populate the dictionary, which is done by the Register (object obj) method (see Figure 4). Note that the Register method does not need to be on the IDependencyResolver interface because only the creator of the SimpleDependencyResolver will register dependencies. Typically this is done by a helper class called in the Main method during application startup. How does CompanyService find the SimpleDependencyResolver so that it can locate its dependencies? We could pass an IDependencyResolver into every class that needs it, but this quickly becomes cumbersome. The easiest solution is to place the configured SimpleDependencyResolver instance into a globally accessible location, which you can do using the static gateway pattern. (You could have also used the singleton pattern, but singletons are notoriously difficult to test. They are one of the biggest causes of tightly coupled code that’s difficult to test, as they’re little more than global variables in disguise. Avoid them if possible.) Let’s take a look at the static gateway, which I’ll call IoC. (Another possible name is DependencyResolver, but IoC is shorter.) The static methods on IoC match the methods on IDepenEven if your architecture is dencyResolver. (Note that layered, you may still have IoC doesn’t implement IDependencyResolver because tight coupling, which can static classes cannot impleimpede the testing and ment interfaces.) There is evolution of your app. also an Initialize method that accepts the real IDependencyResolver. The IoC static gateway simply forwards all Resolve requests to the configured IDependencyResolver: public class IoC { private static IDependencyResolver s_Inner; public static void Initialize(IDependencyResolver resolver) { s_Inner = resolver; } public static T Resolve () { return s_Inner.Resolve (); } Full-Fledged IoC Containers A simple IoC container such as SimpleDependencyResolver enables you to stitch together loosely coupled components. However, it lacks many of the features present in full-fledged IoC containers, including: • Wider configuration options, such as XML, code, or script • Lifetime management, such as singleton, transient, per-thread, or pooled • Auto-wiring dependencies • The ability to wire in new functionality Let’s discuss each of these features in more depth. I will use Castle Windsor, a widely used open source IoC container, as a concrete example. Many containers can be configured through an external XML file. For example, Windsor can be configured as follows: } During application startup, you initialize IoC with the configured SimpleDependencyResolver. You can now replace poor man’s dependency injection with IoC.Resolve in the default constructor: public InvoiceService() : this(IoC.Resolve (), IoC.Resolve (), IoC.Resolve ()) { } XML configuration is advantageous, as it can be modified without recompiling the application, though it does often require an application restart for the changes to be applied. It is not without its disadvantages though, as XML configuration tends to be very verbose; errors aren’t detected until runtime; and generic types are declared using the CLR’s backtick notation, rather than the more familiar C# generic notation. (Company.Application.IValidatorOf is written as Company.Application.IValidatorOf`1[[Company.Application.Invoice, Company.Application]], Company.Application.) In addition to XML, you can configure Windsor using C# or any other Microsoft .NET Framework-compliant language. If you isolated your configuration code in a separate assembly, changing configuration would mean simply recompiling the configuration assembly and restarting the application. You can script Windsor configuration using Binsor, which is a domain-specific language (DSL) built specifically for configuring Windsor. Binsor allows you to write your configuration files in Boo. (Boo is a statically typed CLR language that focuses on language and compiler extensibility, thus making it well suited for writing DSLs.) In Binsor, the previous XML configuration file could be rewritten as: import JamesKovacs.IoCArticle Component(“Foo”, IFoo, Foo) Note that you do not need to synchronize access to the inner IDependencyResolver, as it is only read but never updated, after application startup. The IoC class provides another benefit—it acts as an anticorruption layer in your application. If you want to use a different IoC container, you simply need to implement an adapter that implements IDependencyResolver. Even though IoC will be used extensively throughout your application, you have not coupled yourself to any particular container. 60 msdnmagazine Dependency Injection Things get more interesting when you realize that Boo is a fullfledged programming language, which means that you can use Binsor to automatically register types in Windsor without having to manually add component registrations, as you would with XML-based configuration: import System.Reflection serviceAssembly = Assembly.Load(“JamesKovacs.IoCArticle.IoCContainer”) for type in serviceAssembly.GetTypes(): continue if type.IsInterface or type.IsAbstract or type.GetInterfaces().Length == 0 Component(type.FullName, type.GetInterfaces()[0], type) Even if you’re not familiar with Boo, the intent of the code should

Table of Contents Feed for the Digital Edition of MSDN Magazine - March 2008

MSDN Magazine - March 2008 Contents Toolbox CLR Inside Out Data Points Advanced Basics Office Space Introducing ASP.NET MVC Loosen Up CI Server Performance Office Development Test Run Security Briefs Extreme ASP.NET Foundations .NET Matters {End Bracket}

MSDN Magazine - March 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.