MEF

I might have become a MEF head…. and I know what you are thinking and the answer is no… I have not resorted to drugs to fix my coding problems. MEF stands for Microsoft Extensibility Framework.

I was watching an interesting DNR TV show yesterday (http://www.dnrtv.com/default.aspx?showNum=130). This show was on MEF. Unfortunately Glen Block did not provide a very good code example on how to implement MEF, however he did get the concepts across. I must say, I like the idea.

Basically, MEF allows you to “extend” existing sealed applications by dropping in DLLs. How this works is when an application needs a piece of functionality, it will signal it needs an assembly that does ‘X’, and MEF will go and find all assemblies that can fullfill that requirement.

This is how it works: Lets say you have an application that needs to perform some sort of comparison (could be String, Int32, Business object, etc). Instead of hard coding those comparisons into your application you can use the Specification pattern and inject an interface (lets say IComparison) into the class that needs to use that comparison. This can also be done using a Service Locator.

Thus, a shared assembly can be used to store these common interfaces that you need to use in your applications. There could be one or many assemblies that use this interface assembly to provide implementations. Lets call one of these assemblies ‘Extensions’. This assembly provides two implementations of IComparison – StringComparison and Int32Comparison. These two classes implement the IComparison interface and implement the necessary methods (like Compare(object1, object 2)).

MEF resides in the System.ComponentModel namespace. In the Extensions assembly you add a reference to it, and mark the classes you want MEF to discover with an [Export] attribute. This attribute has various overloads:

• Just [Export()] allows you to make this specific class discoverable.
• [Export(typeof(IComparison))] will make this class discoverable through the IComparison interface
• [Export(“SomeCategory”)] will make this class discoverable using the custom string type.

The class is not limited to one category however, you can assign multiple [Export] attributes to each class if you so require and thus giving them different categories.

Now, the calling assembly (that needs to use the comparison) will have a reference to the shared assembly (where IComparison resides). It DOES NOT need a reference to the Extensions assembly.

MEF uses Catalogs to define where your assemblies reside – thus you can add it manually, use DirectoryLocator, etc – all these are built in – thus you can just tell MEF that my assemblies reside in some directory and it will do the loading for you. Then you instruct MEF that you require an implementation of IComparison to implement this comparison. MEF will then load those implementations (in our case two of them) into a variable which you have marked with [Import] attribute. You can then use these references as you would any class.

As you can see from this example, it can be very useful in Dependency Injection/Inversion of Control where you want to use Service Locators to fetch an implementation of interface for you. MEF allows you to do this and not worry about the details of dynamically loading DLLs, using refection, etc to get those implementations.

Check it out at http://www.codeplex.com/MEF