Compartilhar via

Managed Extensibility Framework Preview Available

  • Artigo

A few months ago we announced that we are working on a Managed Externality Framework and there was a lot of feedback just on the announcement!   Today we posted the very first CTP of MEF.    I would love to get your feedback on this. 

Many people have noted that the industry has not yet achieved the level of code reuse the Object Oriented Design promised.  One of the reasons for this is the tight coupling that most OO systems tend allow.  Over the last few months (and for some of us, years) we have thought deeply about how we can encourage more reuse.    We believe MEF is part of the solution. 

The MEF provides developers with a framework to easily add extensibility to their applications and with minimal impact on existing code. The application developer can define extension points according to the functionality required of an extension, while the extension developer uses those points to interact with the application.
MEF enables this extensibility to take place without creating a hard dependency in either direction. Applications can be extended at run time without recompilation, and extensions can be used by multiple applications sharing the same extension requirements. MEF also allows an application to delay the loading of an extension while still examining its metadata, enabling efficient traversal of large catalogs of extensions.

There are some great samples included:

HelloWorld: A very simple example to show the concepts.   The Button's Caption is determined at runtime by what component is added.  This can be changed at runtime, and customized based on user, etc.

 public MyHelloWorld()
{
    InitializeComponent();
    CompositionContainer container =
              new CompositionContainer();
    
    container.AddComponent<MefHelloWorld.MyHelloWorld>(this);
    container.AddComponent<ExampleStringProvider>(new
      ExampleStringProvider());
    
    //Alternatively, comment the above and 
    //use the DateStringProvider:

    // container.AddComponent<DateStringProvider>(new
    //               DateStringProvider());

    container.Bind();

    //theButton.Content = "Hello World!";
}
[Import("ButtonCaption")]
public String ButtonCaption
{
    get { return theButton.Content.ToString(); }
    set { theButton.Content = value; }
}

DirectoryWatching: a "Hello World" example, using Directory Watching rather than manual component insertion.  You can simply drop a DLL into a directory to enable new functionality in the app

Calculator: a stack-based calculator example..  You can add some "advanced" opperations that happen to be written in VB just by dropping the extension into a directory. 

image

You gotta have a game right??    Simply open the file menu to load some additional shapes

image

XFileExplorer: a MEF-based file explorer

Again, we'd love to have your feedback and thoughts on this very, very early preview.

Comments

  • Anonymous
    June 05, 2008
    This sounds like a "plugin-model". What is the difference between System.AddIn and MEF?

  • Anonymous
    June 05, 2008
    >>This sounds like a "plugin-model". What is the difference between System.AddIn and MEF? Robert -- someone already asked ;-)  see a detailed answer here: http://forums.msdn.microsoft.com/en-US/MEFramework/thread/cf6b7cbc-1123-4b32-9810-c235d9606b66

  • Anonymous
    June 05, 2008
    Here's another question.  What's the difference between this and Unity or any other DI container?  Furthermore, haven't we (the majority of the community that's been using DI for a while) established that using attributes for injection is not the best approach?  Perhaps I'm missing a nuance of your implementation.

  • Anonymous
    June 05, 2008
    You've been kicked (a good thing) - Trackback from DotNetKicks.com

  • Anonymous
    June 05, 2008
    I don't really see what this gives you over just using a DI container

  • Anonymous
    June 06, 2008
    In a broader sense, reuse is not really a technology problem, IMO, it is a problem of being able to discern the future. What hooks does one permit? Where? You can't really know until you've come in contact with new requirements. You can guess, but that's all you'd be doing. As long as any framework requires knowledge of the future, it wil fail to deliver the promise of reuse. Not that I don't think this API isn't a good idea: it delivers a standard way of doing something that is often required in a software solution. However, alone, I'd say it won't increase reuse one iota. That is the work of smart software architects, who, on their best day, can only make educated guesses about the future.

  • Anonymous
    June 06, 2008
    The comment has been removed

  • Anonymous
    June 09, 2008
    Code Reuse is not a problem with technology but has been primarily determined as an organizational problem whereby it is not encouraged in the IT areas.   Code Reuse requires repositories at different levels but rarely are they ever part of any IT organization's infrastructure.  The second major factor here is a lack of discipline that reuse requires as much as repositories. Providing a new framework to promote code reuse won't do much given the current situations within companies, it will simply promote the use of another framework...