Archive for the ‘patterns’ Category


July 5, 2009

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 ( 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


Event Sourcing

July 3, 2009

I read a very interesting article yesterday. We are busy with a POC on this and will probably be implementing this on one of our big projects coming up.

Marting fowler describes a new pattern called event sourcing ( which is based on the Domain Event pattern. This pattern challenges your thinking around traditional business application development.

The idea is that you have a domain model that is based on state. This state comes in from one or more input sources. These input sources generate events that come into your system. These events get routed to your EventLog.
The EventLog has three purposes:
  • It persists all events it receives (in order) to some repository (in memory, database, etc).
  • It generates events based on the incoming events and forward the events to the EventProcessor.
  • On startup, it will get all available events persisted from the repository and reconstitute the state of the domain.
The EventProcessor propagates the events throughout your domain model.Once the domain receives the events, additional events can be triggered based on domain change. These events get routed to one or more output sources.
What this gives us is that the domain model is completed driven around events. This is especially usefull when working in a publish/subscribe model where your system is receiving broadcast messages (like order price change) from a broadcaster. Only the relevant data is pushed to your system. Because we have a complete log (in order) of events in a repository we can provide rollback or playback functionality. If the system dies for some reason, on startup the domain will reload itself from the repository and be in the correct state because the order of events were persisted.
A very interesting model to adapt when working in a messaging system.