POCO and Unity Application Block Part I

Using Plain Old CLR Objects (POCO) with the Unity Application Block

Plain old CLR objects is a term borrowed from Java (POJO) that refers to objects that are not entangled with framework specific code or dependencies.  For Example, when classes have multiple constructors you can add the [InjectionConstructor] Attribute to the constructor that you want Unity to use.

public class MainFormPresenter
{
    private readonly IProductRepository _productRepository;

    public MainFormPresenter()
    {
        //Do Something Profound
    }

    [InjectionConstructor]
    public MainFormPresenter(IProductRepository productRepository)
    {
        _productRepository = productRepository;
    }

    public IList<Product> GetAllProducts()
    {
        return _productRepository
            .Query(p => p.Name.StartsWith("M"))
            .OrderBy(p => p.Name)
            .ThenByDescending(p => p.ListPrice)
            .ToList();
    }
}

This, however, is where POCO advocates become vocal.  The problem is by adding the attribute our class has been “polluted” with Unity specific code and it would become difficult to replace Unity with another framework.  Fortunately, Unity also allows you to accomplish the same thing using API configuration or XML configuration files.

Selecting a Constructor using the Unity API

Using the Unity API to configure which constructor to use takes just one line of code:

IUnityContainer unityContainer = new UnityContainer();

//Configure Container
unityContainer.RegisterType<IProductRepository, ProductRepository>()

//Configure constructor for MainFormPresenter
unityContainer.Configure<InjectedMembers>()
    .ConfigureInjectionFor<MainFormPresenter>(new InjectionConstructor(typeof (IProductRepository)));

Lines 7 and 8 tell unity that when the class MainFormPresenter is instantiated use the constructor that has a single parameter of type  IProductRepository. This information is difficult to find in the documentation but is straight forward and easy to read.

Selecting a Constructor using XML

Configuring Unity using an XML file is a bit more verbose but fairly easy to understand nonetheless. The first step is to tell Unity to load your config file using code similar to this.

IUnityContainer unityContainer = new UnityContainer();

//Configure Container
UnityConfigurationSection section = (UnityConfigurationSection)ConfigurationManager.GetSection("unity");
section.Containers.Default.Configure(unityContainer);

Next, update your App.config, Web.config or whatever config file you choose to use to include information to inform Unity which constructor to use.

  1: <types>
  2:   <type type="UnityDemo.Views.MainFormPresenter, WindowsFormsApplication3">
  3:     <typeConfig extensionType="Microsoft.Practices.Unity.Configuration.TypeInjectionElement, Microsoft.Practices.Unity.Configuration">
  4:       <constructor>
  5:         <param name ="productRepository" parameterType="AWRepository.Products.IProductRepository, AWRepository">
  6:           <dependency />
  7:         </param>
  8:       </constructor>
  9:     </typeConfig>
 10:   </type>
 11:   <type type="AWRepository.Products.IProductRepository, AWRepository"
 12:         mapTo="AWRepository.Products.ProductRepository, AWRepository"/>
 13: </types>

Lines 4-8 inform unity which constructor to use in much the same way as the API configuration preceding it.  The <dependency /> element tells unity to resolve the parameter type (IProductRepository in this case) using the mapping it already contains. 

Conclusion

Allowing configuration information, such as constructor selection, without modifying the injected class not only allows POCO but also allows us to use non-friendly dependency injection classes that we cannot modify.   For example,  Generated classes for LINQ to SQL DataContext contains 4 constructors, two with one parameter and two with two parameters. Due to the similar constructor signatures Unity will not be able to determine which one to use and will throw an exception if no guidance is provided. Fortunately we can use API or XML configuration to inform Unity how to handle these unfriendly classes.  I tend to favor the use of Attributes because they are easier to use and easier to understand intent. However, It is critical to provide indirect configuration to allow the use of classes that are not friendly to dependency Injection and to allow POCO classes when there is a need.

In my next post I will discuss how to Configure Unity for Property Injection without using the [Dependency] Attribute

Related Posts:

POCO and Unity Application Block Part II – Property Injection 

Bookmark It