A friend and co-worker of mine recently gave a presentation to a group of developers on the Managed Extensibility Framework. Before this presentation, I had played with MEF and even made a few sample applications out of it and thought I had a pretty good grasp of how it worked.
He started explaining MEF at a high level but rather than just giving out a bunch of boring details, he compared application development with MEF to building things with Legos. After listening to his presentation, I had a new-found appreciation for the power, elegance, and simplicity of MEF and the application development scenarios it enables.
The analogy goes a little something like this:
You start off thinking about the application that you want to build in terms of compose-able parts. These parts might be pieces of your app that perform discrete tasks like download YouTube videos, read blog posts, access a particular web service – whatever. The point is to think of your app as an assembly of re-usable, compose-able parts. Think about these compose-able parts like Lego bricks:
Each of these Lego bricks has a specific purpose. Some of them are “all purpose” blocks – rectangles and squares that you can just mash together into bigger shapes. Others are special purpose – windows, doors, wheel-and-axles and even more special purpose from the custom kits like bits of the wing from the Millennium Falcon, LEDs that stick onto other Lego bricks, etc. Think of the nubs on top of the Lego brick as the exports and the holes on the bottom as imports. Only pieces whose nubs and holes connect properly can be matched up (composed).
So you’re the person building this Lego structure (Application). In your head (or on paper if you’re following a kit) you’ve got a good idea of the kinds of compose-able parts you’re going to need to build your house, castle, space ship, e-Commerce app, etc. Where do you get these parts/bricks from?
In the Lego world, if you were me as a kid – you get them from big giant Rubbermaid tubs. If you’re someone else you might get them from a kit box like this one:
This box of compose-able parts from a kit box is akin to a MEF Catalog. A MEF Catalog is basically a big giant bin filled with discovered compose-able parts. These could come from the file system in a directory, they could come from the currently executing Assembly, or they could be coming from any custom location – developers can build their own catalogs if they want.
So now you’re ready to rock. You reach into your Lego box (catalog) and pull out your Lego bricks (parts) and now you need to assemble them. If you’re a hard-core Lego person you don’t just sprawl out anywhere to do your build. You probably have a desk, a card table, or some cordoned off section of your bedroom floor. This area in which Lego assembly takes place is a composition container. The reason for this container is because you are building one specific thing, so you don’t want to get parts unrelated to your task mixed in with your Millenium Falcon cannons and likewise, you want to make sure all the parts you are going to need are within arm’s reach.
A composition container is basically a context in which all the parts from a catalog are resolved, including all imports and exports. Object instances are wired up in here and references are maintained where they need to be maintained if recomposition is going to take place.
So the standard MEF developer workflow is this:
- Grab a parts catalog (which can be an aggregate of other catalogs)
- Set up a container with all the parts from that catalog
- Build all the objects from the instructions (imports and exports) within the container
Your opinion may vary, obviously, but this Lego analogy was so compelling and did such a good job of clarifying the role and purposes of the different parts of MEF that I felt compelled to share it.