Tame Your Software Dependencies with Dependency Injection & Common Service Locator Library

kick it on DotNetKicks.com
StumbleUpon.com
Save to delicious Saved by 0 users



Tame your software dependencies with the Microsoft Unity Application Block and Common Service Library Locator in your application code. Source codes provided including the unit tests.


Preface

 

Hi, in this post I will explain and demonstrate how we can strive for a loosely coupled design for our dependencies in the software application with Dependency Injection (DI) container and the Common Service Locator Library from Microsoft Pattern & Practices group. In other word, we try to achieve loosely coupled design in such as way that the application interacts with the different components it relies on through the component interfaces instead of the component's concrete dependencies with the help of DI container. So, the architecture will be much more flexible and open to change without having most of the codes need to be modified.

Most of us familiar with the layered approach and may have been practicing it all these while in the software development. The idea of layered approach is to logically separate the application components into groups that represent distinct roles and functionality with the aims to make the application more maintainable and easier to scale out when necessary to improve performance. Generally, an application consists of number of basic layers. The most common is the three layer approach which comprises the data layer, business layer and the UI layer. In this simple three layering scheme, the UI layer talks to the business layer and the business layer talks to the data layer in a one way direction from top to bottom. The same goes to the dependencies that flow the same way with each of the layer being aware of the layer beneath it but the current layer is unaware of the layer above it.

This is a good design technique as it allows the factoring of responsibilities and separation of concerns into multiple layers of a software application. However, if we see it from the testability perspective, how testable of each of this layer when in isolation? We know that there is a direct coupling of upper layer to the lower layer. Take for e.g. the business layer is intimately dependent on the data layer. If the business layer is taking a direct concrete references to the data layer, then it would be impossible to test the business layer in isolation because all the real dependencies of the data layer such as the database and other states have to be ready at the time when the business layer needed to be unit tested. This incurs high cost for practicing Test Driven Development as all the concrete dependencies need to be in a known state such as the database initial data and time spent in running the tests would be significant as accessing external resources such as file and database takes times. Since we are using the real dependencies during the tests, then those failing tests are hard to be diagnosed as the failure in the business layer may be related to the problem in the lower data layer. Diagnosing the root cause is time-consuming and tedious as testing the business layer alone has to take care of the errors and problems in the lower data layer. Other problem would be the ease of maintenance of the codes. Changes in the lower layer will force the immediate layer above it to be modified in some way due to the implicit and explicit dependencies that the upper layer has on the lower layer.

 


Dependency Injection Container Comes to Rescue

 

Based on what I have described, building loosely coupled application/components requires more than just separating the application into its distinctive layer of responsibilities. It requires the effort of programming against the abstraction. Another term for this is programming to contract. The high level component doesn’t depend on the low level component but its abstraction or interface instead. However, programming to contract does not solve the problem completely as the concrete implementations of the dependencies need to be instantiated somewhere in the application. One of the ideal solutions is to make use of the Dependency Injection container to return the concrete implementations. The container centralizes the objects creation for the dependencies and also provides the flexibility to switch among different implementations of the same interface/abstraction without having the client code knowing about it.

Generally, if you read up the definition of Dependency Injection from Wikipedia, it is process of supplying an external dependency to a software component. It is a specific form of Inversion of Control, IoC where the process of getting the dependency is the process being inverted. Hypothetically, a business component makes calls to a service component by instantiating an object of the callee component and it is the responsibility of the business component to take care of the whole life cycle of the instance. With dependency injection, this process is handled by a dependency provider which is also referred to as container in the current trend. The business component will no longer create the instance of the callee but requests it from the container. The container returns a reference to the implementation to the business component so that it can accomplish its task. The container itself knows how to orchestrate the dependent and manage its life cycle. All the boilerplate codes of handling all these are being built into the container itself and the consumer simply request the references. As in most of the containers available nowadays, the types mapping registration is done in the container initialization during run time or through some form of XML file configuration during the design time.  Other mean will be through some form of attribute decoration for the type member that need dependency injection. So, the container knows what and how to return the reference to the implementation instance of the requested/target type.

Most of the containers also support automatic dependencies injection in which the container examines the dependencies of the requested type and create those dependencies without requiring the developers to supply them in the code. Normally, we can see automatic dependencies injection in the constructor and property (setter) injection. In constructor injection, the dependent types listed as parameter(s) in the target’s constructor. When an instance of the target type is requested from the container, the container will instantiate all the dependent types in the target type’s constructor parameter(s) and wire them up with the target type instance. In property (setter) injection, the dependent object is instantiated and wired up with the member of the target type. Usually, the member or property of the target type is annotated with attribute that will tell the container the type member that has dependency injection requirement need to be fulfilled.

 

 

Factory vs DI Container

 

At this juncture, I would like make clear that the factory pattern/class has been very popular and it is a common way to provide dependency injection in the component or class to achieve loose coupling. Through this way, the instance of the dependent type or class is constructed and initialized in the factory class and injected into the calling component or class. The factory class is rarely reused outside of the creating component. Its purpose merely serve the dependencies needs of a few related creating components within a particular business domain or a family of calling classes in the class hierarchy. In other words, the factory is a specialized class to serve particular dependency needs. On the other hand, container provides a layer of abstraction to house components. Within the container, it has generic factory classes to instantiate instances of classes.

In fact, container works at a broader level and does more than what factory pattern can offer besides instantiating objects, resolving and injecting dependencies. It allows us to define what type of dependencies to inject into each target type and configure the instantiation mode for each type. For e.g. should a new instance of a type be created every time it is requested or the same instance is reused (singleton). Container itself also provides lifetime management. It keeps references to the objects it instantiates to manage their life cycles, or keep the objects alive for reuse later such as the singleton object. Type or class that is configured to return a new instance whenever a request is made, container will forget their references so that the garbage collector can reclaim their storage. So, Dependency Injection Container/Framework just make it easier.

From other point of view, factory pattern requires the developers themselves to write code for constructing, initializing and wiring up the dependencies. All the factory classes has to come into the picture of the class API design. Whereas, with the Dependency Injection Container/Framework, we outsource all these responsibilities to a third party component which is separated from our application code. With the high level of configurability of DI container, any types of instances can be easily created and configured. The configuration information is placed in a central place for easy modification later. Through the file based configuration, dependencies change can be made without having to recompile the factories.

Anywhere, in a small application with a few types of instance to be created, factory pattern works very well and it is simple to understand. Besides, it provides a great learning experience in designing factory classes in a software application.


 

Microsoft Unity DI Container (Unity Application Block 1.2) & Common Service Locator Library 1.0

 

This post is not about what is Dependency Injection in depth. It is about putting it into action with the Unity DI Container. I will demonstrate how to apply the Dependency Injection and Common Service Locator Library to the sample code that I have prepared for my previous post on Repository, Specification, Unit of Work, Persistence Ignorance POCO with Microsoft ADO.NET Entity Framework Beta 2 and Using the Mocking Framework - Moq. The sample application comes with this post won’t be must different from those found in the posts mentioned just now. In fact it is the same sample application with some modifications to demonstrate the purpose of this post. Anyway, prior to completing this post, I have refactored the sample project code and the changes are briefly explained at this post; Repository, Specification, Unit of Work, Persistence Ignorance POCO with Microsoft. ADO.NET Entity Framework 4.0 Beta 2 – Code Update.

You will see the use of DI container, in more specific, the Microsoft Unity DI Container 1.2 to inject life (dependencies) in to the sample application. There are lots of DI containers out there available for .NET platform. To name a few, Castle Windsor, Spring.NET framework, StructureMapLinfu, Seasar2 Container and etc. Some of these containers have been in existence for over a period of time and well ahead of the Microsoft Unity DI container. I choose Unity container because I have used it before and I am more familiar with Enterprise Library from Microsoft’s pattern and practices group, compared to other open source enterprise frameworks. Other than that, Unity Application Block has a comprehensive documentation and quick starts for beginner.

Besides, you will also see the container abstraction library, Common Service Locator Library being put into use to provide container abstraction. So, you can have your application code to switch among different type of DI container without having it to tie to the specific container. It provides you a way to evaluate each of the available container in term of its performance and how it best fits your application needs before you finally decide the specific container you really want to use. It also fulfills the need of your customer who wants to use different DI container on request. So, it will spare you the need of having to modify your application code to take a different dependency on a particular DI implementation. By relying on the Common Service Locator Library, we can make our application container agnostic. Of course, it will create one more level of indirection which is sometimes not desirable. There are Service Locator and Dependency Injection pattern out there to help us to build loosely coupled components. There are lot of article out there provide full coverage of both. If you are interested to know further and want to contrast Service Locator to Dependency Injection, you can follow Martin Fowler's article here. Without much ado, let have a look at the Solution View of the Dependency Injection & Common Service Locator Sample Application in Figure 1.0.



 Figure 1.0 Solution View of the Dependency Injection & Common Service Locator Sample Application

Based on Figure 1.0, you will notice that there are  four more assemblies in the red rectangle box being introduced in the SharedLibrary solution folder. The assembly Microsoft.Practices.ObjecBuilder2.dll, Microsoft.Practices.Unity.Configuration.dll and Microsoft.Practices.Unity.dll are required for the Unity container to work. Whereas, the assembly Microsoft.Practices.ServiceLocation.dll is the Common Service Locator Library which provides container abstraction. You will also notice Moq.dll assembly which is the library for the Moq object framework that provide mock implementation of the dependencies for the object being unit tested. In our sample application, the CustomerRepository is the object being unit tested. If you are interested to know more on using the Moq, mock object framework, please follow my previous post on Using Mocking Framework - Moq.

You will also notice the UnityServiceLocator C# source file in the solution view. UnityServiceLocator class is the adapter for UnityContainer to the IServiceLocator interface in the Common Service Locator Library. This adapter class is necessary as in our sample application, we no longer code against the specific container interface for Unity, IUnityContainer. Instead, we will code against IServiceLocator interface to access the Unity container's services indirectly. This avoid hard references to the IUnityContainer and it will allow us to switch different DI containers without changing the code in our sample application as long as we have the adapter for each of the different DI container.

BootStrapper and UnityBootStrapper are used for initialization of the application before the unit tests start. Inside the bootstrapper, it can initialize any global variables and setting or whatsoever that are needed by the rest of the application. In my sample project, I used it to initialize and configure the Unity container instance with the types mapping information stored in the Xml configuration file in a format that is understandable by the Unity. The Unity instance will be used for the rest of my unit tests. You can refer to the Unity Application Block 1.2 - October 2008 chm documentation file for more information on Configuring Containers at Design Time which will tell you all the possibility that the Unity Container can be configured. Figure 1.1 is a snapshot of my Xml configuration information used in the sample project.

The InitializeTestEnvironment contains a public static method, Initialize which is decorated with the Microsoft.VisualStudio.TestTools.UnitTesting.AssemblyInitializeAttribute identities this method to be run before all the unit tests. Within this method, the UnityBootStrapper is instantiated to trigger the initialization.

As usual, the CustomerRepositoryMoqTest contain the unit tests to test the business layer types, CustomerRepository but with its dependency being mocked by the Moq mocking object framework. The CustomerRepositoryTest uses the real dependency for the unit tests. Moq is used to replace the real dependency with the mock object that mimics the behavior of the real dependency and enable us to carry unit tests even without the presence of the real dependency. This is only possible if the higher level API interact with the lower level dependencies via interfaces instead of the concrete or hard references.


Figure 1.1 Snapshot of the Xml Configuration Information Used in the Sample Project.

In refactoring the sample project codes to use the Dependency Injection Container, I have decided to drop all the factory classes as  the Unity container provide object creation and other services that can replace these factory classes. However, there is one exceptional case to the UnitOfWorkFactory. This class is renamed to EntityUnityOfWork factory later in the MyCompany.Data.Entity project. The container is best to use when creating objects that are fixed at design time or without decision-making on what type of object to be created at run time. The EntityUnitOfWork encapsulate the logic for object creation that depends on whether it is in web or non web context. So, it is best handled with the factory classes.  Figure 1.2 shows all the factories that are removed in red rectangle box.


Figure 1.2 Solution View for the Factory Classes that are Removed

ObjectContextFactory is removed and is replaced with the ServiceLocator in the AspNetObjectSourceLifetimeManager, ScopeObjectSouceLifetimeManager, StaticObjectSourceLifetimeManager in the MyCompany.Data.Entity project.  Figure 1.3 shows how the ObjectContextFactory is used to create ObjectContext instance in the AspNetObjectContextLifetimeManager prior to the code update and Figure 1.4 shows how the ServiceLocator is invoked in the AspNetObjectSourceLifetimeManager to return a new instance of the object context after the code update.


Figure 1.3 - ObjectContextFactory Create ObjectContext Instance in the AspNetObjectContextLifetimeManager



Figure 1.4 - ServiceLocator Create ObjectContext Instance in the AspNetObjectSourceLifetimeManager


The same also goes to the ObjectContextLifetimeManagerFactory where it is replaced by the use of ServiceLocator as in Figure 1.5.
 

Figure 1.5 - ServiceLocator Create ObjectSourceLifetimeManager Instance in the Constructor of the EntityRepository Abstract Class

The RepositoryFactory has been removed but replaced with the transparent dependency injection technique. What is transparent dependency injection ? It is a coding style where we explicitly define the dependency interface in the class/type constructor letting the outside world know clearly what the dependencies the class/type has. Figure 1.6 shows the dependency for the CustomerRepository class, IRepository is explicitly defined in the parameterized constructor and there is no parameterless constructor. By explicitly defining the dependency in the class constructor, it enables the Constructor Dependency Injection and more specifically, Automatic Dependency Injection supported by the chosen container. Figure 1.7 shows the Unity Container provides the automatic wiring up of dependencies for the CustomerRepository class.


Figure 1.6 - Explicit Definition of the Dependency in the Constructor for Business Layer Type, CustomerRepository


 Figure 1.7 - Automatic Dependency Injection for Business Layer Type, CustomerRepository

In Figure 1.7, I have programmed against the ServiceLocator which return the UnityServiceLocator instance through the public static Current property. The UnityServiceLocator has encapsulated the UnityContainer instance through this statement, ServiceLocator.SetLocatorProvider(() => new UnityServiceLocator(unityContainer)) which set the ServiceLocator to use the container instance I have passed through the lambda expression; within the UnityBootStrapper. When the GetInstance() method invoked by passing the type parameter, CustomerRepository, the Unity Container will examine the dependencies of CustomerRepository class and create those dependency implementations as necessary based on what we have configured the Container to return during the design time (Xml configuration file) or runtime.  Alternatively, we can also manually pass in the dependency instance to the CustomerRepository's only one parameterized constructor as shown in the commented out statement in Figure 1.7.

By having the dependencies explicitly listed in the parameterized constructor, we can know what dependencies the class/type need by looking at the public signature. If we are using the mocking framework to provide the mock objects for these dependencies, we can simply pass these mock objects to the class being unit tested through its parameterized constructor after the expectation on the mock object is setup. It also save us lot of time to find the class's dependencies. Figure 1.8 shows the CustomerRepository class under unit testing being passed the mocked implementation of its dependency using Moq Mocking Framework in the CustomerRepositoryMoqTest. In the sample project code, only the CustomerRepositoryTest make use of the Unity dependency injection container to get its dependency. Since, the CustomerRepositoryMoqTest get its depedency through the moq object mocking framework, then the mocked object is passed directly to the constructor of CustomerRepository.


Figure 1.8 - Passing Mocked Implementation for CustomerRepository's Dependency through Constructor

This will end my post. If you want to know more on the opaque vs transparent dependency, I would recommend you to read the Nikola's article on Dependency Injection that reveals some of the best practices in his thought. You can download the source code for this post at the Code Download section below.

Code Download : Tame Your Software Dependencies with Dependency Injection & Common Service Locator Library. (This application sample requires Visual Studio 2010 Beta 2/RC that can open C# project. Right click on the above link and choose Save Target As. Rename the extension from .pdf to .zip once you have downloaded the file. Let me know if you have any problem running the code.)

See you in my next post.
Bye and stay tune...

Some Other Readings

 

2. Dependency Injection in Libraries




Repository, Specification, Unit of Work, Persistence Ignorance POCO with Microsoft ADO.NET Entity Framework 4.0 Beta 2 - Code Update

kick it on DotNetKicks.com
StumbleUpon.com
Save to delicious Saved by 0 users



Code Re-factoring for the sample project attached with the post Repository, Specification, Unit of Work, Persistence Ignorance POCO with Microsoft ADO.NET Entity Framework 4.0 Beta 2. Brief explanation of the changes are included.


Hi,  while I was preparing my post on Tame Your Software Dependencies with Dependency Injection & Common Service Locator Library, I have further refactored the sample project codes for my post on Repository, Specification, Unit of Work, Persistence Ignorance POCO with Microsoft ADO.NET Entity Framework 4.0 Beta 2.

The changes that I have made center around the MyCompany.Data.Entity project under the FrameworkSource logical folder as indicated  below. Figure 1.0 and Figure 1.1 show the solution view of  MyCompany.Data.Entity before and after code refactoring. After the code refactoring, you will see an additional project solution; MyCompany.Data holds all the interfaces/abstraction for implementing the Repository, Unit of Work and Specification pattern. The MyCompany.Data is totally decoupled from any data infrastructure concern (data access technology agnostic).



 Figure 1.0 MyCompany.Data.Entity Solution View before Code Update.



 Figure 1.1 MyCompany.Data and MyCompany.Data.Entity Solution View after Code Update.


The changes are for better level of abstraction in which I have included the IUnitOfWork, IUnitOfWorkFactory, IUnitOfWorkScope interface in the MyCompany.Data framework project. The ObjectContextLifetimeManager has been renamed to ObjectSourceLifetimeManager and is moved from the MyCompany.Data.Entity to MyCompany.Data project. The rationale is the ObjectContext form part of the ObjectContextLifetimeManager name implies that it is highly tied to the ObjectContext type used in the Entity Framework. Renaming it to ObjectSourceLifetimeManager will give a better impression that it is an abstract class for anyone wants to implement a lifetime manager for managing the data source of a particular data access technology. For e.g. the ISession used in the NHibernate for the persistence context.

The UnitOfWork has been made an abstract class in the MyCompany.Data project from the concrete class in the MyCompany.Data.Entity. It includes a few abstract methods and a template method; CommitCore that the concrete class must implement. You can notice that the EntityUnitOfWork implement UnitOfWork abstract class in the MyCompany.Data.Entity. The EntityUnitOfWork provides unit of work implementation for any application that make use of the Entity Framework as data access infrastructure. However, anyone intends to implement a totally different unit of work implementation can choose to implement the IUnitOfWork interface which exposes only the Commit interface method.

The Repository class remain as an abstract class in the MyCompany.Data project. However, its protected properties; ObjectContext and ObjectSet have been moved into the higher level assembly/project; MyCompany.Data.Entity to break the coupling to the Microsoft Entity Framework in the MyCompany.Data project/assembly. So, I can say that the MyCompany.Data project/assembly is data access technology agnostic. The Repository class that provides an in-memory like collection interface for accessing domain objects against the Entity Data Source (ObjectContext) is now named as EntityRepository in the MyCompany.Data.Entity assembly/project.

The rest of the changes you can easily spot in the MyCompany.Data.Entity project. The changes are pretty on the names of the types such as the AspNetObjectSourceLifetimeManager, ScopeObjectSourceLifetimeManager and StaticObjectSourceLifetimeManager. The changes in their name are not necessary but I think changing it to ObjectSource instead of using the ObjectContext will more reflect the concrete data source lifetime manager inherits from the abstract class ObjectSourceLifetimeManager even though the three concrete class are actually managing the ObjectContext in the Entity Framework. By looking at ScopeObjectSourceLifetimeManager, you will know that it inherits from the abstract class ObjectSourceLifetimeManager.

The last, you will see there is an additional EntityUnitOfWorkFactory in the MyCompany.Data.Entity project which implements the IUnitOfWorkFactory interface. The simple static factory, UnitOfWorkFactory inside the MyCompany.Data.Entity project previously has been removed. The rationale is not to fix a particular UnitOfWorkFactory implementation required by the UnitOfWorkScope in MyCompany.Data project. Anyone can implement the IUnitOfWorkFactory interface to provide his own implementation of Unit of Work factory used by the UnitOfWorkScope. Anyway, the default implementation of UnitOfWorkScope is provided as it is. It is the way I think it should work and it may not meet the all the needs and expectations of some applications. Anyone can implement his own version of the UnitOfWorkScope in his own project or assembly to replace this default implementation. As you can see, the UnitOfWorkScope is being used in the higher level component; MyCompany.Data.Entity and MyCompany.Business.AppName business layer project. You can replace it with your own implementation in your higher level framework or bussiness project.

Finally, the idea of creating a separate MyCompany.Data project is to have a better level of abstraction and separation of concern. You can see better level of abstraction with several interfaces and abstract classes such as IUnitOfWork, IUnitOfWorkFactory, IUnitOfWorkScope, UnitOfWork and etc because the concrete implementations can be varied by programming against the abstraction or contract. By programming against the abstraction or contract, changes in the implementation of the abstraction won't affect the higher level component that depends on it.

Decoupling the higher level component from its lower level dependencies by interacting with the dependencies via interfaces rather than their concrete classes give another advantage. It facilitates unit testing as we can simply substitute the interface with fakes or mocks for any of the dependencies. Another term is called dependency inversion because we can supply any implementation of the dependencies via the interfaces to the higher level components normally through the parameterized constructors of the higher level type.

I have included the new updated project source codes in the code download section below. This source code will be used as reference project for my next post on Tame Your Software Dependencies with Dependency Injection & Common Service Locator Library.


Code Download : Repository, Specification, Unit of Work, Persistence Ignorance POCO with Microsoft. ADO.NET Entity Framework 4.0 Beta 2 - Code Update . (This application sample requires Visual Studio 2010 Beta 2/RC that can open C# project. Right click on the above link and choose Save Target As. Rename the extension from .pdf to .zip once you have downloaded the file. Let me know if you have any problem running the code.)

See you in my next post.
Bye and stay tune...