I have been happily using the Unity container for over a year now. I had previously written my own IoC framework in Silverlight and used some other off the shelf and custom home-grown containers. I have recently been getting started using MEF in Silverlight as part of some up and coming Patterns articles.
When you scratch the surface of MEF, I’ll warn you that you may be Underwhelmed. What, exactly, is this? The Ultimate IoC container? What is this doing for me that Unity wasn’t already doing for me? In fact, you can implement the IUnityContainer interface with MEF so what’s the big deal?
Is the big deal…
- That MEF is the Visual Studio 2010 extensibility mechanism? No. Microsoft has claimed that they needed MEF for internal efforts like this. I believe they are earnest, that this is not just a public “Look at us eating our own dogfood” showing. Still, Microsoft needed the Entity Relation model beneath the Entity Framework and we saw how well that was received by the community.
- That MEF works in Silverlight? No. Other IoC containers were ported to Silverlight 2 long before Unity or MEF. We’ve been able to use the same container for Silverlight/WPF/ASP.net/Winforms/Console apps for a long time.
- That MEF has cool features like Catalogues, Dynamic Recomposition, Lazy<T> ? No. These features are cool and I plan on exploring them further and talking about them to anyone who will listen.
No, the big deal is that MEF is shipping with .NET 4.
So what, you say? Let me explain. A lot of you probably listen to .NET Rocks. I do, I enjoy it. The hosts are funny, the guests are bright, and I get bite-sized updates on what is going on out there in areas of the development universe that are important to me but not so important as to be in my overloaded RSS list. .NET rocks succeeds for various reasons and to hone in on one of the big whys let’s take a look at one possible way to group developers:
- Brand new developers.
- Developers who are lazy clock-punchers who don’t care about their craft whatsoever. Enough said about these folks.
- Developers who know enough to know there are better ways. They struggle within the bureaucracy. They’ve heard testing is good, but why? They feel they probably need abstractions, but where? Some don’t quite have the motivation or the skills the find the answers themselves; some have never been afforded the opportunity to break out.
- Developers who think they have all of the answers but are full of $(‘.crap’).
- Developers who mostly “get it”, who have the motivation and skills to find the answers, refine their craft, and make things better.
Based on my own experience Group #3 makes up an awful large percentage of the developer world. A lot of the folks in Group #5 start here until something snaps within them and they decide to stop playing WoW and get serious about figuring out what it takes to get better. These #3 folks want to learn but the lure of American Idol keeps them from catching up on those blogs. They want to try a new pattern but the Architecture Police have decreed that they must never do X and always do Z. Maybe the political war required to get a new library into the solution to try a different way kills any initiative. Maybe their employer never springs for training. More often than not, the high turnover in IT isolates developers from the long term perspective that would otherwise be a great teacher. Which abstractions worked and which turned out to be nightmares or at best simply unnecessary? Who knows. We don’t go back and ask because we’re afraid of the answers, and to be fair we all hate each others’ code anyway.
The .NET rocks show and things like it is a little beacon of light, a reminder that some people are really doing things right out there, and staying on the cutting edge, and delivering a lot of value. But, Damon, how does this relate back to MEF? Because Group #3 is looking for guidance. How many guests have debated which Data Access technology Microsoft “wants us to use” ? Do they want me to use LINQ to SQL or Entity Framework? Yes, the good folks behind door #3 who are in the .NET space overwhelming look to Microsoft for that guidance. When Microsoft showed creating SQL DataAdapters inside button click event handlers that’s what they did. When Microsoft said Stored Procedures are the way that’s what they built. When Microsoft said SOA was good we learned SOAP. When Microsoft endorsed jQuery we learned jQuery.
By putting MEF in the .NET framework the community of well-meaning folks who want to do better are going to see a new message, some new guidance. “Microsoft wants me to think of my applications differently.” Microsoft is telling me that my apps should be composed out of modules, perhaps modules hidden behind interfaces. I should worry about the physical location of a module or its implementation later and program against abstractions. When I write a class I should think about what the responsibility of this class is and what its dependencies are. Microsoft is telling me to get onboard with loose coupling. I don’t need to petition my overlords to bring in a new framework because the only thing between me and MEF is:
Microsoft has always been a Platform company. I like my Zune, the Xbox is cool, I’m a PC, and maybe the Microsoft Stores will be cool. But let’s be real: what Microsoft does better than anything else is to build something that other people use to build something. By including MEF in the core toolbox Microsoft is getting behind a lot of solid development ideas and removing another barrier between the Average Corporate Developer and Better.