MSDN Magazine - March 2008 - (Page 57)

Figure 3 Dependency Injection [Test] public void CanSubmitNewInvoice() { Invoice invoice = new Invoice(); ValidationResults validationResults = new ValidationResults(); IAuthorizationService authorizationService = mockery.CreateMock (); IInvoiceValidator invoiceValidator = mockery.CreateMock (); IInvoiceRepository invoiceRepository = mockery.CreateMock (); using(mockery.Record()) { Expect.Call(authorizationService.IsActionAllowed( invoice, InvoiceAction.Submit)).Return(true); Expect.Call(invoiceValidator.Validate(invoice)) .Return(validationResults); invoiceRepository.Save(invoice); new InvoiceService( new AuthorizationService(), new InvoiceValidator(), new InvoiceRepository())); As you can see, the UI would have to be aware of not just its own dependencies but also the dependencies of its dependencies, ad infinitum, down to the data layer. This is obviously not an ideal situation. The easiest way to solve this dilemma is with a technique that we’ll call the poor man’s dependency injection. Poor man’s dependency injection uses the default constructor of the higher-level component to supply the dependencies: public InvoiceService() : this(new AuthorizationService(), new InvoiceValidator(), new InvoiceRepository()) { } } } using(mockery.Playback()) { IInvoiceService service = new InvoiceService(authorizationService, invoiceValidator, invoiceRepository); service.Submit(invoice); } reconfigure the ServiceLocator to substitute an AuditingInvoiceRepository at deployment time for specific IInvoiceRepository requests. But even with these disadvantages, service location is easy to understand and better than hardcoding your dependencies. Notice how I’m delegating to the most overloaded constructor. This ensures that the class’s initialization logic is identical regardless of which constructor is used to create an instance. The only place the class is coupled to concrete dependencies is through the default constructor. The class remains testable because you still have the overloaded constructor that allows you to supply the class’s dependencies during unit testing. Containers Dependency Injection When unit testing a higher-level component, you want to provide fake or mock implementations for its dependencies. But rather than configuring a service locator with the fakes or mocks and then having the higher-level component look them up, you could just pass the dependencies directly to the higher-level component via a parameterized constructor. This technique is known as dependency injection. An example is shown in Figure 3. In this example, I’m creating mock objects for InvoiceService’s dependencies and then passing them to the InvoiceService constructor. (For more information on mock object frameworks, see Mark Seemann’s “Unit Testing: Exploring the Continuum of Test Doubles” at msdn.microsoft.com/msdnmag/issues/07/09/MockTesting.) In sum, you specify the behavior of the InvoiceService by defining how it will interact with the mocks rather than verifying the state of the InvoiceService after the test is run. By using dependency injection, you can easily supply your higherlevel components with their dependencies in unit tests. However, you still have the problem of how to locate a class’s dependencies outside of a unit test—either while running the application or in an integration test. It would be foolish to expect the UI layer to provide the service layer with its dependencies or the service layer to supply the repository layer with its dependencies. You would end up with an even worse problem than what you started with. But let’s suppose that the UI layer was responsible for supplying the service layer with its dependencies: // Somewhere in UI Layer InvoiceSubmissionPresenter presenter = new InvoiceSubmissionPresenter( Now it’s time to introduce inversion of control (IoC) containers, which provide a central place to manage dependencies. In reality, a container is nothing more than a fancy dictionary of interfaces versus implementing types. In its simplest form, an IoC container is just a service locator by a different name. Later on, I’ll examine how a container can do much more than just service location. Getting back to the problem at hand, you would like to completely decouple InvoiceService from concrete implementations of its dependencies. Like all problems in software, you can solve it by adding another layer of indirection. You introduce the notion of a dependency resolver, which maps an interface to a concrete implementation. You then use a generic method that takes an interface T and returns a type implementing that interface: public interface IDependencyResolver { T Resolve (); } Let’s implement the SimpleDependencyResolver, which uses a Figure 4 SimpleDependencyResolver public class SimpleDependencyResolver : IDependencyResolver { private readonly Dictionary m_Types = new Dictionary (); public T Resolve () { return (T)m_Types[typeof(T)]; } public void Register (object obj) { if(obj is T == false) { throw new InvalidOperationException( string.Format(“The supplied instance does not implement {0}”, typeof(T).FullName)); } m_Types.Add(typeof(T), obj); } } Dependency Injection march2008 57 http://msdn.microsoft.com/msdnmag/issues/07/09/MockTesting

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.