MEF and IoC/DI (1)

Inverse of Control (IoC) and Dependency Injection (DI) are widely used patterns in software development. Here I call DI in short for IoC/DI afterwards. I have used StructureMap in .Net as a framework to inject instances to my application, a nice way to decouple interfaces and implementations(see my previous blog posts). MEF(Managed Extensibility Framework) is another very hot topic in .Net recently. Now it is a part of new libraries in .Net Framework 4.0, and it is also available for .Net Framework 3.5. Actually, MEF started as an Open Source project at CodePlex by a group of Microsoft developers. It is claimed with more features than DI.

In the past weeks, I have tried MEF as an alternative way to StructureMap to provide DI. It works out very great. MEF may have much rich features than StructureMap since the later is mainly focused on DI while the former is on the extensibility and discovery ability. Since I am more familiar with DI, therefore, in the view of ID, in this and following posts, I’ll explain in detail how I use MEF as a DI framework.

Overview

Let's stand back a few of steps to get a big picture of implementation of DIs in an application. From my past experience of using StructureMap, I treat it as a library to hold a DI container in cloud.

First, I provide it with information about mapping relations of class to class or interface to class to the container. Then either I fetch instances by interfaces or class from the container directly whenever I need them, or I mark my codes with some kinds of indicators such as attribute so that the cloud will be able to inject appropriate instances automatically. As a result, I would not need to know how instances are created, nor need I to have any knowledge of what actual instances are mapped. This will let me to concentrate on my business logic or working on components individually.



The above is the picture I perceive. With this picture in mind, I found that MEF works in a similar way. I don’t need to change my interface library and components (3), nor my business implementation or application (4). What I need to do is to understand the structure and the way of how to add/load my mapping relationships through the block (2) to the new container (1), and understand how to request instances from the DI framework to my application (4), or to construct my application so that instances will be able to inject to "magically".

In the above picture, there are two doted arrows, which mean that there are two ways to call or reference to each other. One is direct call or request. For example, you can write codes to let the container to know what the mappings are, and you can make a call to the container to get an instance by type. In other words, you have direct access to the container. Another way is that you don't need to write codes to do any direct call at all. Most DI frameworks provide some ways to mark dependencies and injects so that DI framework will be able to detect or load mappings and inject instances automatically. For example, you may construct a mapping configuration file, or add some special attributes to your classes, property variables, constructors or method parameters. Both MEF and StrcutreMap support these two ways; however, they provide different strategies and implementations in terms of how to describe the mappings and to provide injections.

In this and following posts, I'll discuss how to use MEF to describe mappings and injections. My practice only exposes the tip of iceberg, as MEF has much rich infrastructure and features. Even though, I think my DI exercise may help you better to understand MEF. During my exploration, I have done several times of refactory of my codes, which were quite rewarding learning experience.