Addicted to MEF

Be careful of MEF.  It’s pure and potent.  Use it once and you’ll be hooked!

I’m fashionably late to the party (I got distracted by XNA) because the Managed Extensibility Framework (MEF) is already in Preview 5, but my god of a coding partner (David Wynne) and I have recently been building apps using MEF.  It’s stunning – nothing short of a revolution (and a revelation) in application architecture.

You could say that MEF is just IOC/DI on steroids, but it makes a leap that changes the way you build applications forever.  It’s probably as big a leap as Dependency Injection itself.  And it’s great that it’ll be part of .Net 4.0 so maybe there’s some hope that this is really the beginning of a great world-wide clean-up in the way we write applications.

In the application we’re currently building we needed to simulate plugging electrical devices into a wall socket at home.  A kettle is dumb and just draws power from the house circuit and you can just buy one, plug it in and it works.  You don’t have to re-wire the house every time you plug a new appliance in.

So it is with MEF.  We wrote a Kettle class and started the application and there it was!  The Kettle even provides its own UI so that we can switch it on and off.  Hardly rocket science I know, but the simple fact that the application doesn’t know anything about my kettle means that I can write a Television class in 2 seconds, start my app and it’ll be there – plugged in and complete with its own UI (this time the switch will need to include a stand-by mode).

What’s more, if I put my Kettle and Television into a separate assembly I can just drop it into a directory that the app is watching and they will just appear in my app straight away.  I can switch them on and start using them immediately.

That’s a plug-in architecture to die for.  And it couldn’t be easier to use.

Back in 2000 I was blown away by how .Net itself blurred the boundaries between components and classes.  It made building components a doddle.  Prior to that you had to use COM and it was a complete nightmare.  Now, with MEF, building a component that quite literally just plugs into your app is easier than ever.

They call it Dynamic Composition and it promotes the most loosely coupled architecture I’ve ever seen.

Visual Studio 2010 should be fully WPF.  Unfortunately only the code editor has been built in WPF.  But the great thing is that it uses MEF.  So when it launches next year there will be an explosion of (hopefully) great productivity plug-ins simply because it’s now so easy to write them.  Imagine how cool it will be to drop the plug-in into the relevant directory and start using it in Visual Studio without even restarting it. Try doing that in Outlook 2003!

That’s a revolution!

So how is it done?  It’s as simple as annotating your classes and class members to indicate what constitutes the “Imports” and “Exports” that the Composable Part needs and provides.  A Catalog discovers these at runtime and works with the CompositionContainer which acts like a dating agency, matching the Imports and Exports together by their contract (internally a string, which usually represents the exchanged Type).  Optionally, you can provide metadata that can be used to finely tune the match-making process.  The result is a set of instantiated components that have all their Imports satisfied (if you implement IPartImportsSatisfiedNotification an event is raised when this happens).  You can ask the Container to re-Compose itself at any time.

David’s blogging about how we used MEF to create a really simple, clean Model-View-ViewModel architecture for WPF applications that beats the traditional Dependency Injection / Service Locator pattern hands down.  Go to his blog and see how nice it is.