How to write MEF in 2 hours or less
It took me a while to get around to this blog post, I promised Glenn that I would write it ages ago.
The title of this blog post, which is admittedly provocative, refer to a (I believe intentional) misinterpretation of a comment of mine in a MEF talk. It might also explain my general attitude about software in general.
MEF is a pretty big library, and it does a whole host of things. But when talking about it, there are specific features that keep getting mentioned over and over, probably because they are:
- Really nice features.
- Demo very well.
A good example of that is MEF ability to import new types on the fly. It is something really nice, but it isn’t something that is really impressive to me. Doing dynamic loading isn’t really hard. That has led me to make the comment that turned into the title of this post.
The actual comment I made was: “I can implement this feature (dynamic loading) in less than two hours.” The problem is that that was interpreted as saying that I can implement MEF itself in 2 hours (just to be clear, it isn’t possible). What is possible, however, is to implement interesting parts of MEF for a particular scenario in a short amount of time.
In fact, most of the time, I can implement the features that I find attractive in some software (not limited to MEF) faster than I can learn how to use that software in the first place. Granted, it may be a single purpose, only-works-under-the-following-set-of-assumptions implementation, but it will work, it will be faster out of the gate and it will limit the number of dependencies that I have to manage.
It is something that you have to consider, because sometimes you want to put those responsibilities at the hands of some other party because you don’t want to deal with that. Sometimes you explicitly want to do it yourself because giving up control on this thing (or adapting to the way some library does it) is not acceptable.