text: Damon Payne
  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…
  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:
  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:
  using System.ComponentModel.Composition;
  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.
  This weekend I was trained in the ancient art of Sabrage for Champagne (or sparkline wine). Rather than the pedestrian practice of removing the cage and pushing on the cork with your thumbs, you chop the top off of the bottle with a champagne saber or chef’s knife. Here’s my first successful cut:
  There is, as you may suspect, a trick to it. I was taught the ancient secrets by sensei Phil at Thief Wine. As if my love for Champagne wasn’t already great enough, now I also have an amazing party trick to go with it.
  I have just switch DamonPayne.com over to some better iron. If you’re seeing this, all is well!
  Theme by Mads Kristensen
  Damon Payne is a Microsoft MVP specializing in Smart Client solution architecture.
  Tweetses by damonpayne
  Get notified when a new post is published.