+972 52-548-6969
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.
Comments
Reasonable point. However other team members may be not so happy to gettting used to ad hoc frameworks/libraries that grow right and left on the project. Good thing to keep in mind as an option though.
I tend to do it the other way around -- if there is an existing library, I will generally throw away my code that does the same, take the library, tweak its API into submission and use that.
Because it saves on maintenance, unit-testing, and libraries tend to evolve themselves, growing new features just when I need them.
Fortunately MEF will become a part of the framework - the dependency that we have anyway.
Your previous post from 2007, while effective, isn't quite "from scratch" which is what I thought you meant (though you never said so). I guess the question is then, would you use MEF or use your own hot swap code? What are the advantages and disadvantages of each? I know others are writing on this, but I'm interested in your take.
Ryan,
that depends on too many variables. As for "from scratch", I strongly believe that working on the naked CLR is sacrilege.
You should really do an audit at my company then....
Got blamed because I used a javascript BSD licence library haha
This does, of course, assume that there aren't subtleties to the framework that you don't understand yet. After all, I doubt you'd apply this argument to Castle Windsor or NHibernate. The "interesting part" of Castle Windsor is constructor injection, and that's pretty easy to write from scratch.
It's only later that you discover that your two hour IoC container doesn't really cut it in the more complex scenarios. Equally, I imagine it would take a while to start to really appreciate the subtleties of what Hammett's solving.
Finally got around to finding this.
Oren, I don't have any issue with anything you said above. You may very well be able to implement your own feature set for your apps in a shorter amount of two. Certainly MEF supports many scenarios some of which you might never need, though others you may be discarding prematurely.
The thing about MEF though is it is not designed for you. And what I mean but that is not being tongue and cheek. I mean, it's main goal is not for the individual it is for the ecosystem.
It is designed for an ecosystem of extenders. It introduces a common approach for building that ecosystem across many applications.
It is designed to support some very large extensible applications like Visual Studio.
Albeit the above being the case, we've worked hard to ensure that you can "turn up the dial" of complexity as you need it, and can get off the ground with a minimal set. You don't need to be Visual Studio to take advantage of MEF.
I can't help but think that you are oversimplifying the capabilities MEF provides, and that those features would not be so trivial to implement, however I am not going to go there.
I decided to put a few more thoughts in a post: codebetter.com/.../...or-less-i-am-all-for-it.aspx
So why not build your own transitors, CPUs, RAM, HD, and video card?
Jon,
Those don't take two hours or less
But even if they did - I would guess most of us would still buy from a vendor.
I know from experience that you can whip together a dynamic loader in a short amount of time. But it won't have the full feature set of MEF - it won't be the same framework that other people use (and used by Visual Studio, the SQL Modeling Tools etc).
There is a benefit to resiting the NIH urge:
1) How long will it take the next person who builds on your framework to learn it (once MEF become part of the framework - new developers should automatically understand how to use it).
2) How easy will it be for you to maintain? How many new features will get added to MEF over time?
I am guessing you know these things - but perhaps others reading your blog don't.
Comment preview