MSDN Magazine - March 2008 - (Page 61)

be clear. Simply by adding a new service to the JamesKovacs.IoCArticle.Services namespace, that service is automatically registered as the default implementation for its service interface. Let’s say I create the following class: public class AuthorizationService : IAuthorizationService { } Figure 5 Using the Decorator Pattern public class AuditingInvoiceRepository : IInvoiceRepository { private readonly IInvoiceRepository invoiceRepository; private readonly IAuditWriter auditWriter; public AuditingInvoiceRepository(IInvoiceRepository invoiceRepository, IAuditWriter auditWriter) { this.invoiceRepository = invoiceRepository; this.auditWriter = auditWriter; } public void Save(Invoice invoice) { auditWriter.WriteEntry(“Invoice was written by a user.”); invoiceRepository.Save(invoice); } If any other class declares a dependency on IAuthorizationService by including it as a parameter to its constructor, Binsor will automatically wire it up without having to specify that dependency explicitly in a configuration file! You can find more information on Binsor at ayende.com/Blog/category/451.aspx and Boo at boo.codehaus.org. Lifetime Management } The SimpleDependencyResolver always returns the same instance that was registered for an interface, which effectively makes that instance a singleton. You could modify the SimpleDependencyResolver to register a concrete type rather than an instance. Then you could use different factories to create instances of the concrete type. A singleton factory would always return the same instance. A transient factory would always return a new instance. A per-thread factory would maintain one instance per requesting thread. Your instancing strategy is only limited by your imagination. This is exactly what Windsor provides. By applying attributes in the XML configuration file, you can change which type of factory is used to create instances of a particular concrete type. By default, Windsor uses singleton instances. If you wanted to return a new Foo every time an IFoo was requested from the container, you would simply change the configuration to: Auto-Wiring Dependencies Auto-wiring of dependencies means that the container can examine the dependencies of the requested type and create those dependencies without the developer having to supply a default constructor: public InvoiceService(IAuthorizationService authorizationService, IInvoiceValidator invoiceValidator, IInvoiceRepository invoiceRepository) { } When a client requests an IInvoiceService from the container, the container will notice that concrete type requires concrete implementations of IAuthorizationService, IInvoiceValidator, and IInvoiceRepository. It will look up the appropriate concrete types, resolve any dependencies that they might have, and construct them. It will then use these dependencies to create the InvoiceService. Auto-wiring obviates the need to maintain default constructors, thus simplifying code and removing many classes’ dependency on the IoC static gateway. By coding to contracts rather than concrete implementations and using a container, your architecture will be much more flexible and amenable to change. How could you implement configurable audit logging for the InvoiceRepository? In a tightly coupled architecture, you would have to modify InvoiceRepository. You would also need some application configuration setting to indicate whether audit logging was turned on. In a loosely coupled architecture, is there a better way? You could implement an AuditingInvoiceRepositoryAuditor, which implements IInvoiceRepository. The auditor only implements auditing functionality and then delegates to the real InvoiceRepository, which is supplied in its constructor. This pattern is known as a decorator (see Figure 5). To turn on auditing, you configure the container to return an InvoiceRepository decorated with an AuditingInvoiceRepository when asked for an IInvoiceRepository. Clients will be none the wiser since they are still talking to an IInvoiceRepository. This approach has a number of benefits: 1. Since InvoiceRepository has not been modified, there is no chance that you would have broken its code. 2. AuditingInvoiceRepository can be implemented and tested independently of InvoiceRepository. Thus you can ensure that auditing works correctly regardless of whether you have an actual database. 3. You can compose multiple decorators for auditing, security, caching, or other purposes without increasing the complexity of InvoiceRepository. In other words, the decorator approach in a loosely coupled system scales better when adding new functionality. 4. Containers provide an interesting application extensibility mechanism. There is no reason that AuditingInvoiceRepository had to be implemented in the same assembly as InvoiceRepository or IInvoiceRepository. It could easily have been implemented in a third-party assembly that was referenced by the configuration file. Loosen Up for a Change Even though your software architecture is layered, you may still have tight coupling between your layers, which can impede testing and evolution of your app. But you can decouple the design. Through the use of dependency inversion and dependency injection, you can reap the benefits of coding to contract rather than concrete implementation. By introducing an inversion of control container, you can increase the flexibility of your architecture. In the end, your loosely coupled design will be more responsive to change. ■ Dependency Injection march2008 61 http://ayende.com/Blog/category/451.aspx http://boo.codehaus.org

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.