Building the Hello MEF dashboard in Silverlight 4 - Part I

In my last post I illustrated some of the basics of MEF through a Hello MEF dashboard app that I used in my PDC talk. In this series of posts, we’ll build that application from scratch and then go even further than we did in that talk. This might take several posts, I am not sure yet, we’ll just have to see ;-) We’ll build the app in an incremental fashion, revisiting different parts along the way in order to introduce new functionality.

Before you invest the time, I’ll give you a preview of the topics we’ll cover along the way.

• Exports / Imports / Part Initializer – All that jazz
• Export metadata
• Custom exports
• Overriding Part Initializer
• Dynamic XAP downloading

In this post, we’ll cover just the first bullet.

To follow along, you will need Silverlight 4 and the Silverlight 4 toolkit. You can download Silverlight 4 beta  here and the toolkit here.

The App

Below is a screenshot of the dashboard application.

May not look very complicated, but what we’re showing here is actually quite sophisticated. The dashboard itself is a dumb shell. The two “Hello MEF” widgets you see are actually exports that are discovered by MEF. The dashboard itself has not knowledge of what it will find, but it does know how to place things that are provided to it, and it has different locations on the screen where things can go. If you’re familiar with Prism, these are very similar to regions in principle though instead of modules pushing content into regions, MEF is pulling the content from whatever is available. More on this later.

Note: I’ll admit, I suck as a designer though I think I could be good if I REALLY try :-) Nice thing about SL is you don’t have to be, as your friendly neighborhood designer can make something hideous a work of art. With that note, don't expect a work of art out of this post.

Step 1 – Create the app

Nothing fancy here, just create a new Silverlight application. Enter HelloMEF as the name.

Leave the “Host the Silverlight application in a new Web Site” checked. We’ll use this later as we get into XAP partitioning.

Step 2. Create the dashboard UI.

For this dashboard we’re going to create something simple, amazingly simple, amazingly stupidly simple. But it works. We’ll create a StackPanel with two items control which will be populated with our widges. Jump into your MainPage.xaml and paste the following.

<UserControl x:Class="HelloMEF.MainPage"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
    xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
    mc:Ignorable="d"
    d:DesignHeight="300" d:DesignWidth="400">
    <StackPanel x:Name="LayoutRoot" Background="Black">
        <Border Background="Cyan">
            <ItemsControl x:Name="TopWidgets" Height="Auto" FontSize="30"></ItemsControl>
        </Border>
        <Border Background="Yellow">
            <ItemsControl x:Name="BottomWidgets" Height="Auto" FontSize="30"></ItemsControl>
        </Border>
    </StackPanel>
</UserControl>

Step 3. Find and show the widgets – Importing many

Our dashboard is supposed to populate itself with widgets. The first thing we need to think about is what exactly is a widget :-) In MEF when we have the concept of a contract. A contract represents something that will either be provided (exported) or consumed (imported). The easiest way to think about it for now is what type is the extension. In the case of our dashboard let’s just assume each widget is a UserControl. We could create a new base type or an interface, but we don’t need to. UserControl will do just fine.

So now we need to tell MEF we need a collection of UserControl, that is we want to import many UserControls. And for that we have the ImportMany attribute.

First add a reference to System.ComponentModel.Composition, and System.ComponentModel.Composition.Initialization.dll. To find them you’ll need to browse to your Silverlight SDK directory (C:\Program Files\Microsoft SDKs\Silverlight\v4.0\Libraries\Client). Next go into the code-behind of MainPage.xaml.cs and overwrite the class with the following.

using System;
using System.Windows.Controls;
using System.ComponentModel.Composition;
namespace HelloMEF
{
    public partial class MainPage : UserControl
    {
        public MainPage()
        {
            InitializeComponent();
        }
        [ImportMany]
        public UserControl[] Widgets { get; set; }
    }
}

Basically we’re saying “MEF, give me the widgets”

Once we have the widgets, we need to show them on the screen. For now, let’s assume all widgets will go in the same ItemsControl. Let’s add the logic to the constructor.

using System;
using System.Windows.Controls;
using System.ComponentModel.Composition;
namespace HelloMEF
{
    public partial class MainPage : UserControl
    {
        public MainPage()
        {
            InitializeComponent();
            foreach (var widget in Widgets)
                TopWidgets.Items.Add(widget);
        }
        [ImportMany]
        public UserControl[] Widgets { get; set; }
    }
}

Step 4: Create a widget – Export

Now that we’ve got our basic Dashboard setup, let’s create a widget. Right click on the “HelloMEF” project and add a new Silverlight UserControl specifying Widget1 for the name.

Our widget is also going to be dead simple, and simply be a button. Go into Widget1.xaml and paste the following.

<UserControl x:Class="HelloMEF.Widget1"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
    xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
    mc:Ignorable="d"
    d:DesignHeight="300" d:DesignWidth="400">
    <Grid x:Name="LayoutRoot" Height="Auto">
        <Button x:Name="Button" Content="Hello MEF!" Width="300" Height="100"></Button>
    </Grid>
</UserControl>

Now we need to tell MEF that we want to provide our widget to importers of UserControl. To do this we will Export it. Go into HelloMEF.Widget1.cs and paste the following:

using System;
using System.ComponentModel.Composition;
using System.Windows.Controls;
using System.Windows;
namespace HelloMEF
{
    [Export(typeof(UserControl))]
    public partial class Widget1 : UserControl
    {
        public Widget1()
        {
            InitializeComponent();
        }
    }
}

Notice above we added an Export attribute and specified UserControl as the type. If we did not pass the type, then MEF would have just exported Widget1 as itself, which would not be of much use as the dashboard will never find it! That being said there are times when it does make sense to use the concrete type, but this is not one of them :-)

Step 5 – Compose the dashboard

OK, we’ve implemented our Dashboard, specified our imports, and created our widget. That means if we run the app, we’ll see widgets right? Wrong :-) Try running and you’ll see this nasty exception.

  
What happened? Our Widgets property is null, but why? The reason is because we never told MEF to do anything with it? Yes we put an ImportMany attribute, but MEF needs to somehow our MainPage in order to know it needs to provide anything. Which brings us to our last concept, composition.

In MEF there are basically 3 things you need to do. First two, declare your exports and imports which we did already. Third, tell MEF to actually go and compose, that is satisfy all imports. The places to do this (you can do it more than once) are where there are 1 or more imports and no exports. In this case our MainPage is the place where we import Widgets so that is the place.

Note: We won’t put it in the widgets themselves as they export themselves. Why not? Because when MEF pulls on an export, it automatically satisfies any of the imports on the thing it pulls. There is an exception to this, but we’ll cover it later.

In general whenever you have user controls that are created in XAML, you’ll use this technique. Telling MEF to compose in Silverlight takes only about 12 lines of code. It’s really easy code and 12 lines that are well worth it.

Kidding :-)

To tell MEF to compose you invoke a single call, PartInitializer.SatisfyImports(this). In MEF, anything that has imports or exports we consider a Part, which is why the name. Below is the code added in MainPage.cs

using System;
using System.Windows.Controls;
using System.ComponentModel.Composition;
namespace HelloMEF
{
    public partial class MainPage : UserControl
    {
        public MainPage()
        {
            InitializeComponent();
            PartInitializer.SatisfyImports(this);
            foreach (var widget in Widgets)
                TopWidgets.Items.Add(widget);
        }
        [ImportMany]
        public UserControl[] Widgets { get; set; }
    }
}

Now when we Run, we see our first widget show up. 

Summary

OK, it’s 2:17 am, time to go to bed. I guess this will run several posts after all. :-)

In this post we’ve seen the basics of exporting, importing and composition in MEF. We’ve also touched on the concept of contracts and parts, which we will delve further into the future.

In the next post we’ll cover the following

• Providing / Accessing export metadata
• Other ways to import and a deeper look at contracts
• Providing custom exports

PS: This is not my normal style of posting. I am following in the lead of my mentor, guru and overall awesome guy Brad Abrams. Please feel free to give feedback on how I can improve. I am looking forward to taking this trip with you.

MEF has landed in Silverlight 4. We come in the name of extensibility.

http://www.flickr.com/photos/markusram/3641457838/

At PDC we announced that MEF has is now part of Silverlight 4.

This may sound like alien speak :-), so I’ll break it down for you. It means building maintainable/pluggable RIA apps just got a whole lot easier. 

What is MEF?

The Managed Extensibility Framework (MEF) is a new library in Silverlight 4 for building RIAs that can be incrementally extended. With MEF you extend your apps in a declarative fashion and let MEF do the plumbing rather than writing all the plumbing code yourself.

• It’s for you and your dev team – You can add and replace functionality to the system without having modify existing code. This means you and your QA team are happy because you don’t have to worry about introducing bugs into the existing code base.
• It’s for your customers – MEF allows you to design applications and libraries that can be extended by third-parties after they have been deployed.
• Always there, always ready – In Silverlight, MEF is ready to go whenever and wherever you need it. You don’t have to be an acrobat, or have a masters degree in complexity :-) You just do it.

Also available in Silverlight 3

MEF ships as part of Silverlight 4, but we’ve also made a Silverlight compatible version of MEF available on codeplex at MEF.Codeplex.com.

The Basics

THREE concepts, that’s all you need to know to get going.

• Export to tell MEF you are providing a service or capability.
• Import to tell MEF you need something.
• Compose It – To tell MEF to go do it!

Below you can see the basics in action for creating a Hello MEF pluggable dashboard. First we create a pluggable widget which in this case is a simple user control.

Export it

To tell MEF it’s available, we simply throw an Export attribute on it and specify the contract (in this case we use a type) you want to export it as. We could choose any type that the Widget implements, but to keep it simple, lets just use UserControl. As you can see, we don’t have to derive from any special base types, or use any interfaces, you use whatever class you would like.

Import It  - Import single

Notice our Widget  has a Message property. Let’s let MEF provide that rather than hardcoding it as I want it to be customizable. To tell MEF we need it, we’ll just slap on an [Import] attribute. If we don’t specify a contract for the import, it will just derive the contract as being a string. However, being that we don’t want just ANY string, we want the Message, we can specify a specific contract such as “HelloMEF.Message”.

Next let’s create our message which our widget(s) will import. To do this we’ll create an export, but it will use a feature of MEF called a Field Export. This is because we don’t own System.String and can’t derive from it, instead we want to somehow create an instance of a string and export it as our message. With a Field Export we can do just that as can be seen below. If our needs are beyond simply setting a value which we can do in a field, MEF also supports property exports.

Import It – Import many

Lastly we need our host app to discover the extensions. To do that we’ll do two things. First, we will create a public collection of type UserControl. Next we’ll add an ImportMany attribute, telling MEF that our MainPage needs all exports of UserControl to be injected into it.

Compose It – Satisfy imports

Next we need to somehow tell MEF to go do some work and give it to us. Doing this is very easy, we just drop into the constructor of our MainPage and call the SatisfyImports method. Once we do, our Widgets collection will be loaded up with all available widgets.

Now we can simply loop through that collection and show the widgets, in this case by adding them to an Items control.

We’ve just seen the core essentials of MEF in SL4, that’s all it takes to get going! Our dashboard works, but it’s pretty simplistic. This is just the beginning of what is possible with MEF, we’ve literally only scratched the surface, however even with this small set of tools I’ve just given you, you can accomplish a lot! In future posts (on this blog or others :-) ) and in our Silverlight documentation you’ll see more about what’s possible. I covered some of this in my talk including lazy instantiation, export metadata, custom exports, dynamic recomposition, and application partitioning.

PDC talk

At PDC, I had the pleasure of delivering a talk on building extensible RIAs which is now available online here. As a highlight I was joined by Ariel Ben-Horesh of Sela, and Jackson Harper of the Moonlight team at Novell. 

Check out my PDC talk: Building Extensible Rich Internet Applications with the Managed Extensibility Framework. In addition to seeing MEF in action, you’ll see some work around integrating MEF with Prism and even using MEF on Moonlight, the open source Silverlight implementation. More on this in a future post!

You’ll also see how to surgically add extensibility to an existing application, and how to dynamically partition applications such that functionality is delivered on demand at runtime!

Can’t wait, want more?

• Check out the attached demos (Yes code!) from that talk. (Requires Silverlight 4)
• Head over to MEF.Codeplex.com and download MEF Preview 8 which contains several Silverlight samples including an extensible DataGrid. These samples work on SL3 or on SL4.
• Check out Brad Abrams series on MEF and Silverlight
• Check out Erik Mork’s screencast on MEF and Silverlight.
• Check out these podcasts on MEF and Silverlight

Also watch for Jesse Liberty and Tim Heuer’s blogs as you’ll likely see some MEF/Silverlight content there VERY soon. ;-)

Building extensible RIAs at PDC

This week I’ll be attending PDC in Los Angeles speaking about using MEF in Silverlight.

Building Extensible Rich Internet Applications with the Managed Extensibility Framework 

In Hall F on Thursday at 11:30 AM

Learn how the Microsoft .NET Framework 4 introduces the Managed Extensibility Framework (MEF) for building customizable applications that can easily be extended by third parties. Whether you are building an extensible data grid, a custom rules engine, a pluggable editor, or a composite application such as a pluggable CRM system, you want to learn about MEF. Hear how to use MEF to decouple your applications into more maintainable and testable pieces, and partition your application into dynamically deployable chunks that download on-demand.

If you haven’t heard, MEF is available in Silverlight similar to it’s availability on the desktop.  But what does it mean to build an extensible app in Silverlight? Yes it’s technically possible, but why should you care? In this talk we’ll explore different application scenarios for when MEF is a good fit. We’ll also explore some of the SL specific features we’ve introduced in order to enrich the MEF experience.

Hope to see you there!

Glenn

Should I use MEF with an IoC container? - Part 1

In my post "Should I use MEF for my IoC needs" we took a look at the question of whether or not it is appropriate to use MEF instead of a traditional IoC container. In this post we'll discuss the question of whether or not you should use both an IoC container and MEF in the same application.

MEF and IoC container concerns

As we've mentioned in the past, MEF's primary design in V1 is around open-systems whose components (parts) are dynamically discovered at runtime. IoC containers on the other hand are primarily designed for decoupling a closed (fixed) set of application components in order to improve the maintainability of the system by the engineering team. In other words each is addressing a specific set of concerns. So if that is the case then is it plausable to use both in an application? The answer is Yes. Not only that, but we specifically designed MEF with the idea of integration with other containers in mind. Below will explore one of the key-scenarios for doing this.

Enabling third-party extensibility in an IoC container-dependent application. 

You have an existing customer management system that uses an IoC container such as Castle Windsor which you use in order to promote separation-of-concens and testability. The application leverages advanced Windsor facilities for integrating with NHibernate and for applying cross-cutting-concerns (AOP) such as logging, etc. The loosely coupled design of the system has proven to be greatly beneficial and has minimized the friction for developing and deploying the system through several releases.

At some point requests start pouring in from customers want to create their own extensions in order to customize the application in their specific environments. Additionally several ISVs express interest in providing third-party value-adds such as telephony integration, and scheduling.  You determine that adding a third-party extensibility model to the application makes sense in order to address this opportunity. Through your research you come across MEF and realize that it provides the infrastructure you need for extensibility.  However it does so in a manner that overlaps with many of the functions that Windsor is providing. What to do? Let's explore various options.

a. Migrate the existing code to use MEF and remove the IoC container completely.

One option is to consider ripping out Castle and just using MEF. Technically this sounds reasonable, however after investigation it is not feasible. There are literally thousands of components that are currently registered in the Windsor container. Moving these to MEF involves modfying all of these existing classes in order to make them discoverable by MEF, not to mention refactoring all the places in the application where the container is accessed.  Because the changes are so widespread, the likelihood of introducing  breakages / bugs in the system is very high. Additionally there are the various Castle facilities such as Dynamic Proxy, and NHibernate integration which MEF does not yet support, which will have to authored by the team. The cost / risk of such changes is too prohibitive, not to mention that it seems like it should be unnecessary. 

b. Implement a custom extensibility mechanism built on top of the IoC container?

Another option is to author a home-grown solution. This can be a viable option depending on the needs, and the willingness to author your own solution. For simple cases you can easily facade an extensibility mechanism on top of an IoC. Once you start getting into more advanced features like lazy instantiation, metadata, recomposition and stable composition, you are in for quite a bit of work.

c. Have both the IoC and MEF both present in the same application?

The final option I want to discuss (and the one I recommend for these situations) is to use both. Use the IoC container for addressing internal application decoupling needs, and use MEF for third-party extensibiltiy needs, that is the IoC container for IoCish things and the MEF container for MEFfish things :-) 

This path is appealing for several reasons.

• It works with existing codebases whether they be applications or frameworks. it does not require any significant rewrite.
• It allows leveraging the strengths of each container for the things it does best. For example leveraging MEF's metadata model for discriminating between different extensions vs the dynamic proxy support in Castle.

However, there are several caveats of this approach.  

• It raises questions such as:
  • Which component (part) should live in which container?
  • Who owns the lifetime? 
  • Can a MEF part access services coming from the IoC?  How?
  • Can the IoC access exports coming from MEF?  How?
• It increases complexity in that now there are components living in mulitple places.
• It increases the potential points of failuire within the application.

All of these issues are managable. In my next post we'll see how.

Open-generic support in MEF Contrib

A while ago I said it couldn’t be done, at least without hacky string parsing. Folks weren’t happy and they let us know it including Oren. Our team know the power that open-generic support brings to systems, but at the time there was no clean way to implement it in MEF.  Then a bunch of time passed, and we actually added some APIs to MEF  which suddenly made achieving support a reality (thanks to Wes for pointing the path), and not in the hacky string-parsing way I had described.

It all came together a few weeks ago after I was pairing with my friend Karl Shifflett on the Cider team. We ran into an issue around usage of MEF which really needed open-generics, and without it made me question the usage of MEF for that scenario.  As I have a tendency to do, I then set off on a personal mission to find a solution. And now several weeks and light nights later, and after quite a bit of help from many of my teammates I am happy to say there is one! I am a tech geek so I usually now take the opportunity to dive into all the nitty gritty of what what the implementation is. This time however, I am going to change that tune and only focus on what it is, how you use it and how you can get it (now).

How can I get it?

If you want to get right to the code, then GenericCatalog ships as part of MEF Contrib. I’ve uploaded two projects MefContrib.Extenions.Generics and MefContrib.Extensions.Generics.Tests. You can go grab the source on contrib  here. Andreas is shortly releasing an official release of MEF Contrib, which will contain this in binary form. If you want the binary, tweet Andreas and say I want MEF Contrib!

What is it?

Open-generic support is very simple. It means that you can provide a part with a generic contract, that can be used to satisfy all imports of a closed form of that contract. The canonical example folks use is Repository<T> and IRepository<T>. What I want to be able to do is register a generic Repository such that any imports of IRepository<T> can be satisfied, this IRepository<Customer>, IRepository<Order>, etc can all be handled by a single Repository<T> that is registered in the catalog.

MEF’s attributed model however does not support this, we don’t allow even exporting open-generic types. If you put an export attribute on say Repository<T>, we ignore it. MEF does support closed generic types. For example I can have an importer of IRepository<Customer>, and i can register Repository<Customer> which exports IRepository<Customer>. However, that means that I have to add a specific implementation of IRepository<T> for every repository in existence. This is problematic because the importer doesn’t want to be burdened with having to add these specific implementations, or to know whether or not it even exists.

Enter GenericCatalog

The new GenericCatalog changes that. Generic Catalog is a custom catalog that can both discover open-generic implementations, and create closed implementations on demand. It also supports generic specialization, that is it allows you to register specific implementations of a generic contract, which override the default that will be created by the open-generic. Finally it supports one other requested feature, that is it can create concrete instances that are imported, even if they were not added to any catalog.

GenericCatalog is a decorator. You pass it in it’s constructor all your catalogs, and it sits on top, delegates to the inner catalogs, and intercepts requests for generic types that were not found in the catalog.

How you use it

To see how it works, check out the specification / context below (otherwise known as a unit test)

[TestFixture]

public class When_querying_catalog_for_an_order_repository_and_no_closed_repository_is_present : GenericCatalogContext

{

    [Test]                    

    public void order_repository_part_definition_is_created()

    {

        Assert.IsNotNull(_result.Item1);

    }

    [Test]

    public void order_repository_export_is_created()

    {

        Assert.IsNotNull(_result.Item2);

    }

    public override void Context()

    {

        _result = _genericCatalog.GetExports(_repositoryImportDefinition).Single();

    }

    private Tuple<ComposablePartDefinition, ExportDefinition> _result;

}

Looking at the spec we can see that we are creating the container passing in a generic catalog. We are then asking the container for an IRepository<Order> and we are verifying that we got one.

Notice in the test that we are calling the overload that accepts an ImportDefinition rather than just calling container.GetExportedValue<IRepository<Order>>. MEF creates special kinds of ImportDefinitions when you add an Import to a part. These definitions carry additional information that the generics implementation relies on. When you call GetExport directly on the container however, the definition that is created is a different definition which doe snot carry this information. As such, in order to take advantage of the new functionality, you import the generic type in a part. For example, the IRepository<Order> definition came from this import below.

[Export]

public class OrderProcessor

{

    [Import]

    public IRepository<Order> OrderRepository { get; set; }

}

OrderProcessor is importing IRepository<Order>

How do you setup the container?

In order to setup the container to support open-generics, you create the GenericCatalog passing in all your other catalogs, usually this will be your conventional AggregateCatalog that contains all your catalogs today. For example below in the base context class you can see how we setup the catalog for this test.

public class GenericCatalogContext

{

    protected AggregateCatalog _aggegateCatalog;

    protected GenericCatalog _genericCatalog;

    protected ImportDefinition _repositoryImportDefinition;

    public GenericCatalogContext()

    {

        var typeCatalog = new TypeCatalog(typeof(OrderProcessor), typeof(RepositoryTypeLocator));

        _aggegateCatalog = new AggregateCatalog();

        _aggegateCatalog.Catalogs.Add(typeCatalog);

        _genericCatalog = new GenericCatalog(_aggegateCatalog);

        string orderProcessorContract = AttributedModelServices.GetContractName(typeof(OrderProcessor));

        var orderProcessPartDefinition = typeCatalog.Parts.Single(p => p.ExportDefinitions.Any(d => d.ContractName == orderProcessorContract));

        _repositoryImportDefinition = orderProcessPartDefinition.ImportDefinitions.First();

        Context();

    }

    public virtual void Context()

    {

    }

}

In this case we are creating a type catalog that we are adding our types for our test, an OrderProcessor and a RepositoryTypeLocator (more about that in the next section). Next we are creating an AggregateCatalog, and adding the type catalog to it. Finally we are creating a GenericCatalog and passing it the Aggregate which contains everything else. Next I do a bit of hackery to get the ImportDefinition off of the OrderProcessor in order to do the query in the test. As i mentioned you shouldn’t have to do this, as you’ll be grabbing something from the container that likely depends on the generic import rather than needed it directly.

Type Mapping

If you are following along, you might be asking yourself where are the open-generic types? And that is where GenericTypeMapping comes in. As I mentioned earlier, MEF does not allow exporting / importing  open-generics. To work around that, I’ve introduced a non-generic contract that carries generic type information :-) Not only that, but the implementation types passed in actually are open-generic parts!

GenericTypeMapping accepts two parameters in it’s constructor, one is an open-generic contract type, and the other is an open-generic implementation type. This type also is an inherited export, taking advantage of our new Preview 6 feature which thus removes the need for the attribute on derivers.

[InheritedExport]

public abstract class GenericContractTypeMapping

{

    public GenericContractTypeMapping(Type genericContractTypeDefinition, Type genericImplementationTypeDefinition)

    {

    }

    public Type GenericContractTypeDefinition { get; }

    public Type GenericImplementationTypeDefinition { get; }

}

To use it, you derive from GenericContractTypeMapping for each open-generic type you want to export. You then make sure that it is in one of the catalogs that is passed in to the GenericCatalog. In our example we have a RepositoryTypeLocator which has a contract of IRepository<> and an implementation of Repository<>.

public class RepositoryTypeLocator : GenericContractTypeMapping

{

    public RepositoryTypeLocator()

        :base(typeof(IRepository<>), typeof(Repository<>))

    {

    }

}

Repository<> is a generic part. It supports constructor injection, can have imports / exports just like any other part.

public class Repository<T> : IRepository<T>

{

}

So all you have to do is create generic parts, and corresponding type mappings, put them in the catalog, and as Karl Shifflett says, “DONE!”

How it works (You don’t have to read this)

GenericCatalog is what is doing all the magic here. This guy automatically queries  his inner catalog for all GenericTypeMapping contacts. Once he has them, he takes the types within and adds them to a mapping table from generic contract to generic implementation. Whenever the catalog is queried, it will see if any exports were returned, if not and the importing type is generic, it will grab the generic type definition, and lookup in that table built earlier. If it finds that it can match against that definition, it will grab the implementation and create a closed generic type. It will then add the new type to a TypeCatalog, which it will add to it’s inner catalog.  Once it does this, it then queries the catalog to grab the new export, returns it, and Voila.

You can dig into the source if you want to know more of the nitty gritty.

Will this ship as part of MEF V1?

No. Actually being brutally honest, the implementation here would probably never ship as part of the framework. This is an additive approach to solving the problem of open-generics, but it is not the approach we would choose to ship in the framework. We are looking seriously into baking such support into MEF in the future, but it will not be in V1. If and when we do, I guarantee it will be a much cleaner and deeply integrated part of MEF as opposed to what I am giving you. However, I believe as do others on my team that in the meanwhile, this approach is reasonable. We’ve put this in MEF contrib to ensure that the community can take it forward from here.

We appreciate any feedback. I take full responsibility for any hackiness you find within. :p

Special thanks to all my awesome teammates and to Andreas for help in getting this out the door.

Herding code on MVVM and other presentation patterns in WPF and Silverlight

Recently I had the pleasure of having a nice lively discussion on Herding Code with my cohorts Ward Bell,  Rob Eisenberg and Jeremy Miller around one of our favorite topics, Presentation Patterns. We let the gloves come off and went at it for about 2 hours. The conversation ranged from topics including View First vs VM First, Screen activation, commanding, and databinding. The podcast was a blast.  Special thanks to the Herding Code team for their being great hosts, and for their awesome queuing system. Even I let others speak :-)

Get part I here: Herding Code 57: Presentation Patterns with Jeremy Miller, Ward Bell, Rob Eisenberg and Glenn Block (Part 1)

Should I use MEF for my general IoC needs?

Disclaimer: This is not an encouragement to use MEF to replace your IoC container, these are guidelines to help those who are considering it's use.

This has been a question we hear again and again both internally and externally.  MEF in V1 is targetting third-party extensibility scenarios, or open-systems which discover their components rather than having them explicitly configured. This is why our attributed model was crafted in the fashion that it was.  Now that doesn’t answer the question, “Can I use MEF today for my general IoC needs?”. Like all things in software, it depends ;-), in this case on what your IoC needs are.

Update: The list has been updated based on feedback from my team.

On first glance, MEF may seem to be very similar to your favorite IoC container. However as they say, the devil is in the details. Here are a few details to consider which should help you in your decision and set proper expectations about using MEF:

• If you  need/want centralized configuration of plain old CLR objects (POCOs) then MEF is not the right choice.
  • We do have TypeCatalogs which allow you pick and choose which Types you have in the container, but those types still have to attributed, thus the configuration mechanism is configuring which attributed MEF parts show up. This is because our attributed model is really optimized around discovery of a set of unknown components vs configuring a pre-defined set.
  • As we don't have a central configuration mechanism, we also have no explict way to pipe configuration settings like "Port" or "Uri" into a specific part.
• If you need AOP/Interception like injecting logging, or automatic transcation management then MEF doesn’t include any native support for this.
• Open generics support (register IRepository<> which can handle all IRepository<T> dependencies) is not baked in.
• If you need custom lifetime support such as per-thread, per-session MEF includes only two lifetime models, shared and non-shared. To get more complex lifetimes requires manually setting up container hierarchies. It is doable, but requires work.
• If you need paramterized construction, that is creating a part where specific imports are passed in at the time of construction, then this is also not supported.

In enterprise applications with a large number of different types of components, the above list will probably be more significant. However, if none of the above are core concerns then MEF might be fine for your needs.    MEF does an excellent job of decoupling implementations and assembling component hierarchies, but it is tailored today for implicit composition and discovery.

In the next version of MEF that will ship post .NET 4.0,  we are planning to focus more on explicit composition, and will be addressing many of the items on the above list. Until then, it is likely that there will be some great community implementations such as MEF Contrib which will address many of these concerns, but these are not part of MEF itself.

The spirit of MVVM (ViewModel), it’s not a code counting exercise.

<Warning>Long post follows</Warning>

Lately there is a lot of momentum and interesting conversation around Model-View-View-Model. There’s several good resources out there that discuss the basics of the pattern, who the actors are that are involved and what role the play. I’ll let those speak for themselves, including John Gossman’s great post here, Martin Fowler’s post on the more general PresentationModel pattern and more recently Josh Smith’s MSDN article, Rob Eisenberg’s new series, and Ward Bell’s posts which touch on some of the deeper complexities involved.

In many of these discussions (not including the posts I referred to) it seems like one aspect of ViewModel get’s lost, which is “Why use it in the first place?” This leads to a lot of debate around details of implementation including one item in particular which is whether or not code in the code-behind is an anti-pattern. Building off of the stage Phil set in his great LOD post, I’ll say ViewModel is not a code-counting exercise.

The essence and the spirit

John says in his post, “Model/View/ViewModel is a variation of Model/View/Controller (MVC) that is tailored for modern UI development platforms where the View is the responsibility of a designer rather than a classic developer.  The designer is generally a more graphical, artistic focused person, and does less classic coding than a traditional developer.”

Martin then states in this Bliki that “The essence of a Presentation Model is of a fully self-contained class that represents all the data and behavior of the UI window, but without any of the controls used to render that UI on the screen. A view then simply projects the state of the presentation model onto the glass.” Martin then adds “It's useful for allowing you to test without the UI, support for some form of multiple view and a separation of concerns which may make it easier to develop the user interface.”

From John’s perspective, it is a pattern that enables a UX designer (non-developer) to be responsible for the UI. From Martin’s perspective it’s about separation-of-concerns and testability. So which one is right? I say both. Also notice neither one said anything about having zero-code in the code-behind. Instead they spoke about maintainability.

So what is the spirit of MVVM then? I say it’s building UIs that utilize platform enhancements in WPF and Silverlight to provide good separation between UI and business logic in order to make those UIs easier to maintain by developers and designers.

When I say designer, I don’t mean only the stereotypical guy/gal who wears a black sweater :-). It may also be a developer who is using Blend/Cider to define the UI, which is likely, as we all know hand coding a ton of XAML is anything but fun.

Why have I called out WPF and Silverlight? Because the pattern is specific and solely on the specific data binding, data templates, attached properties and command implementations found in the platform. Presentation Model on the other hand is entirely general and places no such specificity. I would not for example recommend ViewModel as an appropriate pattern for ASP.NET or Winforms, but I would however recommend PresentationModel, in addition to MVP, etc.

It’s not about counting code

They key here (and which I want to touch on) is the last part, “easier to maintain by developers and designers.”. This means (if you buy my definition) that the chosen implementation should consider both aspects of the equation, that is what does it do for the developer and what does it do for the designer. Obviously tradeoffs have to be made, but the key is finding a healthy balance, reducing the negative impact to both.

Which brings us to the code counting question. Does having zero code in the code-behind make the UI easier to maintain? I say it depends on what kind of code you are talking about:

If the code is UI level business logic which does not relate directly to the rendering of the view, such as determining whether or not certain elements are visible, or enabled, then I agree, this kind of code is a separate concern and should not appear in the View at all and be within the ViewModel. I would include in this the XAML, as the XAML is still part of the view. Why shouldn’t this logic be there? Because it makes the UI difficult to maintain by creating a tight coupling between the UI and the logic. It makes it difficult to test, and is also very brittle and likely to break as the UI evolves in response to changing requirements.

On the other side of the coin are UI-specific concerns, I would include in this setting enabled state, visibility or starting/stopping animations as well as even logic that relates to which model data a specific UI element binds to. That may sound contradictory to my previous statement but it is not. What I mean is, the ViewModel should contain the logic to determine whether something is visible or not, and the View should act on that knowledge to then hide the element. Adding this logic to the ViewModel would introduce tight coupling between the ViewModel and the View, this time from the ViewModel side.

Now being that it is a UI specific concern, the next question is how should it be handled, as code in the code-behind or in XAML? And for that answer I would say it depends on the specific concern itself, as well as whether or not there is a UX designer who handles the UI. Even still,  I would look at an approach that best meets the needs of both developers and designers.

Data binding

Let’s take data binding as an example. If I am working with a dedicated UX designer then bindings in XAML is the prevalent technique that our tooling provides for data binding. Now it does negatively impact the development team to some degree in that due to XAML’s very loose nature it is very easy to break and difficult to verify and test. However there’s no other option for the designer other than forcing them to write code, which is how should we say less than optimal.

If there was no UX designer present however, I would see no issue with putting that binding definition in code, even in the code-behind. As developers are used to writing code, not markup, and the developer IDE provides much richer support for developers in code. Now that being said, the API for defining bindings is not really well-suited for doing them in code, but OSS solutions like “Fluent Silverlight” help bridge that gap.

Animations

A different example relates to animations. The user clicks a Save button on the Edit Order screen which requires some UI cue to the user such as an hourglass while the order is saving, and another cue once the Order has saved. The question is where should this logic live? In the XAML or in the code? You could handle this in the XAML by using triggers, attached behaviors and the like. In the case of Silverlight, you don’t yet have triggers yet baked in, but you could look to using those included with Blend.

Now although you “could”, I wouldn’t, though you might feel different. The reason goes back to maintainability, having such logic in the view means once again it is easy to break and difficult to test (How do I know it actually works?). Instead, I would opt in this case to separate into two parts, the pure visual part and the logic. The pure visual would be the hour glass animation, and the saved completed screen which could likely be purely defined in XAML. However, the logic part which determines to show the hour glass while saving is in progress would rest in the code. I would achieve this by adding OnSave,OnSaveCompleted methods to the view which would both contain the logic to actually display the elements.

The ViewModel would get injected with either an interface to the view, or with a set of delegates it could call to once save begins and completes. Yes, I did say I’d put code in the code-behind! That is ok because it is code that relates entirely to a view-level concern. Also I would argue that putting the one line of code in the View, only minimally impacts the designer. They can still verify that the animations works. On the plus side it means that we’re remove one more potential piece of brittle, un-testable logic. Also it improves debugging as a developer can put a break-point on the view methods to and see whether or not they are even getting called, additionally it ensures that an exception is thrown if the animation in question is removed.

Commands and Parameters

The last thing I want to touch on relates to invoking commands, and usage of command parameters through element binding, vs using bound properties on the ViewModel. The user selects an item in the Order list, and double clicks. Do we a) Use element binding and have clicking on the “Open Order” button invoke the OpenOrder command passing in the currently selected order as a parameter, or b) Set the orders list selected item to bind to a SelectedOrder ViewModel property and then have a parameterless OpenOrder command which uses the SelectedOrder order property on the VM itself.

I would argue B over A, and why relates back to the maintainability question. If I use element binding, again I make the view harder to maintain. In this case, I haven’t coupled it to the VM, but I have coupled one part of the View to another part of the View. The impact here is on future refactorings of the View. If move around elements in the view such that the relative binding is broken, I broke my UI, if I use the second approach however, I can re-factor / replace elements all day long without breaking any relative bindings.

Yes, I’ve added properties to the ViewModel, but those properties are easy to discover, and result in UIs that are less prone to break over time. I should also add that using approach B works just as well for a designer, as they can easily bind to the properties on the VM for the parameters and parameterless commands.

Conclusion

In conclusion, the spirit of MVVM is about producing maintainable UIs for the developer and the designer, not UIs that have zero code. I would recommend folks who are developing using the MVVM pattern to focus less on whether or not there is code in the code behind, and rather focus on the type of code and whether it improves / or hinders the maintainability of the UI. Sometimes having a bit of code in the code behind actually goes a long way toward improving it.

What are your thoughts on this topic? I’d love to hear them.

Stable Composition in MEF Preview 6

Nick just posted on a new and very important feature we added in Preview 6 which we call Stable Composition. To give you an idea of why we added this, in the past if you had a part, say OrderProcessor, that had a required import of ILogger, and no logger was present, then composition would fail, and in so doing would corrupt the state of the container. Once that corruption happened, you were basically left with no option but to tear down the container, and in most cases shutdown the application. With Stable Composition the troublesome parts are rejected from the system thus maintaining stability.

In summary, it basically has two components to it:

First, it ensures that only parts whose imports can be satisfied will ever be allowed to enter the system. Those imports might not be satisfied for one of several reasons including the export not being present (Importing ILogger and no loggers are present), or too many exports being present (Importing ILogger and many loggers are present). Note: You can still use the approach described here to provide defaults in the presence of multiple implementations.

Second, this feature ensures that once parts have entered the system, they will never be allowed to enter an invalid state (i.e. their dependency requirements will not be able to be upset). For example if a part in a running system contains an import of a single logger, and one attempts to add a new logger to the catalog/container, then that new logger will be rejected.

In either case, the effect is to reject such parts and their transitive dependencies, meaning the entire object graph that is problematic is pruned. In Nick’s example, A PointOfSale part imports ItemLookup contracts. ProductLookup depends on ProductRepository which is preset, so it is imported without a problem. ServiceLookup however depends on ServiceRepository which the standard POS SKU does not provide, thus ServiceLookup is rejected.

Subtleties of rejection

Now having such a feature present has some subtle implications in particular when the hierarchy of dependencies is deep, and the part at the bottom of the chain is rejected. For example, Shell imports Toolbar, and Toolbar imports the ToolbarButtonState service which is missing some dependency for one reason or another, then the Shell itself will be rejected. If you are debugging the application, you might be staring at the debugger dumbfounded when you see the message “No Exports Found” for Shell. The problem has nothing to do with Shell directly, but it is related to one of it’s deep dependencies.

There are ways to design around this, for example if Toolbar is an optional import on Shell, then Shell will load even if Toolbar is not present. Thus you could check the Toolbar property, determine it is null and throw an exception indicating that there is an issue with the Toolbar or one of it’s dependencies.

Nick has posted an indispensable tool which he discusses in the Preview 6 post which analyzes the container to determine which parts have been rejected and why.  Finally in our next drop, Preview 7, (and in Beta 2) you’ll see we’ve added tracing infrastructure that in the debugger will write part rejection messages to the output window. You will also be able to use the tracing to write to a log file at runtime for diagnosing rejection in a deployment environment.

We are planning further guidance on Stable Composition which will ship with our documentation.

Check out Nick’s post for more details on the feature, and as always feedback is appreciated.

MEF and XAML integration – Self composition

As I am hoping you heard from Nick, we just shipped MEF Preview 6 which includes a version of MEF for Silverlight 3! At the same time that we’ve been wrapping up on our .NET 4.0 release, we are busy working on a proper release for Silverlight vNext. The things you see in MEF Preview 6 for SL3 are just the beginning.

For SL, we are working on among other things, a set of MEF/XAML integration features. One of the problems we want to address is have parts within XAML which are (optimally automatically) composed. That is elements which normally would have to be manually added to the container in the code-behind in order for their imports to be satisfied. For example you drop a control anywhere in XAML that has imports, and it will get composed, regardless of where it sits within the XAML hierarchy.

In order to do this, we’re exploring a pattern we’re calling “Self composition”, that is an unreachable part (one that the container has no access to) can register itself to get composed. The way this works is the part (UIElement) calls a RegisterForComposition method on it’s load event. Calling the method, forces it to get composed by a host-specific strategy, one which in the case of SL might use an app-wide container, or one that is scoped. The important thing is the grid itself is not coupled to how it is going to get composed. For example, see the sample control below.

CustomGrid is a UserControl and it imports a set of IGridBehavior contracts. It’s using MEF for extensibility, thus the application author can deploy behaviors in the container’s catalog, which the grid will use.

So why does the grid need to register itself? Can’t it somehow be created from the container, which will then satisfy it’s imports? Short answer, no. First notice it has no Export, so it will not get picked up by a catalog. But second, the grid itself is declared within XAML, much like any other control, thus the XAML parser is the one who creates it. This would be the case whether it was manually defined within the .XAML file or if the control had been dragged from the toolbox. Thus our only option at that point is to grab the existing instance, and see that it’s imports get satisfied.

But, can’t we somehow take over the creation of the element from XAML, can we have the parser pass of creation to MEF? Actually the XAML 2.0 parser does provide hooks for factories for doing this, however after investigating, there’s a bunch of “devil is in the details” type issues around us doing this, which prevent us from taking this approach, including significant performance hurdles.

One option is to consider using markup extensions, for example an {ImportMany} ME that is a service locator that can be used within XAML. This would allow setting a Behaviors Dependency Property to all imports of IGridBehavior. This could work, however it means that every user of the grid, must explicitly specify one or more markup  extensions each time they use the grid, something that is leaky, and very poor from a usability perspective. As a side note, we are actually looking to add Markup Extensions for explicitly specifying imports on Dependency Properties, but that is geared more towards the user of the control vs the author.

Another option is to consider using attached properties, for example a “Compose” attached property would allow specifying Compose=True on our Grid.

Although this is less painful then having to specify all the gory details, it still means that the user of the control must explicitly set this wherever the use it. It means the control author cannot transparently decide to start using MEF without impacting every single XAML file that has ever sited that control.

Now all that being said, in general we're of mixed feelings on the team on the self-registration approach:

On the down-side:

• Having parts have to compose themselves is a violation of SOC, in an ideal world, a part should never be responsible for telling itself to get compose. It’s generally a bad idea.
• It’s a DRY Violation, my part has imports, yet I still have to “Tell” it to compose itself.
• It poses several challenges relating to lifetime management.

On the up-side:

• It allows for components which are instantiated by the runtime (in this case FrameworkElements in XAML), and normally unreachable by the container to be able to leverage MEF. This means frameworks (including our own) and applications can gradually migrate to leverage MEF rather than having to be completely re-written / designed in order to leverage composition.  It also means that you can use MEF where you see fit, regardless of whether the framework infrastructure supports it.
• The pattern can even be extended outside of XAML, for example the same approach could work in Winforms, or ASP.NET Web Forms, or even Mobile. This is possible, because the design relies on a host-specific strategy, thus ASP.NET could provide a per-request container, etc.
• Self-registered parts are not coupled to a specific container instance. It's up to the host strategy to decide the container.

What do you think? Do the pros outweigh the cons? Or should we hold off on introducing such functionality because it will cause more harm than good?

Your candid feedback is appreciated.

Meffifying Windows Azure

Magnus has been off doing some interesting work around integrating MEF with Windows Azure. The first question you might be asking is Why?

In his words, he set out to build a template for Windows Azure templates that:

In the post he shows how to take the RoleManger and expose it through MEF, thereby making it pluggable. He then creates a mock Role Manager for use in his unit tests, thus removing the dependency on all the Azure infrastructure.

I am guessing this is the first of many posts to come on MEF and Azure.

For more, check out Magnus post here.

Upcoming talks at NDC in Oslo and Poland

Next week, I am heading to Europe for two weeks to give several talks. My first stop is NDC 2009, where I’ll be delivering the following talks:

• Framework Design Guidelines
• Building Maintainable Enterprise Applications with Silverlight and WPF
• Building openly extensible applications with .NET Framework 4.0

NDC looks like an amazing event with a great lineup of speakers. I am hoping to be able to attend a few talks so I can soak up all their goodness. All my talks are in one day, so it’s going to be real wild ride!

Next is on to Poland for a 5 city user group tour in: Olsztyn, Toruń, Warszawa, Kraków, Katowice where I’ll be speaking about building extensible apps, or other topics if folks attending would like (comment to this post if you have other topics)

If you are attending NDC or will be in any of the cities mentioned, I look forward to chatting with you about how we can build better software!

Customizing container behavior part 2 of N - Defaults

Before I get into the post, let me start off with a word of advice for new bloggers. Never say in a post, this is the first of many to come. RESIST! You are just setting yourself up for never doing that second post. I know as the last post in this series was five months ago. ;-)

In the last post, I introduced the concept of ExportProviders as a way to customize how the CompositionContainer discovers exports. One of the primary use cases for doing this is to provide default exports, which is particularly important for cases where you are importing a single value for which there are multiple present. The common case I like to use is the overused Logger example. Let’s say you have multiple loggers in the system, which are used for different functions. One logger logs locally, while others can log remotely perhaps invoking a web service, or using MSMQ. These loggers are all pluggable, as different organizations that use the app may have different needs. Each of these loggers export an ILogger contract.

Now most of the time when logging occurs the local logger is sufficient. It’s only exceptions to the rule that require the special loggers. And this is where you run into a problem. How do you specify that you need to import that default logger, where there are multiple present? In the default configuration of MEF, the only way to really handle this if you are using imports is to either create a specialized contract for the default logger say IDefaultLogger which is imported, or to import the entire collection lazily using Export<ILogger> and then looking at the metadata for each to find the right one. You could also create a custom service called LoggerService, which imports all the loggers finds the default one, and then returns it when LoggerService.DefaultLogger is called. None of these are optimal though.

For example, you could do this….

[Export]
public class LoggerManager : ILoggerManager
{
    [ImportingConstructor]
    public LoggerManager(Export<ILogger,ILoggerMetadata>[] loggers)
    {
        var logger = loggers.Single(e => e.MetadataView.IsDefault==true);
        DefaultLogger = logger.GetExportedObject();
    }
    
    public ILogger DefaultLogger { get; private set;}

}

The problem is this means the LoggerManager has to have hard knowledge of which logger is the default. It also means the logger itself needs to somehow declare that it is the default, which is problematic because one logger might be the default in one app, but not in another. Separation of concerns anyone? Even worse you might have two loggers that say they are the default!

Now there are other mental hoops you can jump through to find a workable solution, but it’s a lot of pain when what you really want you want to do is tell MEF’s container somehow “This is my default logger for this application”. Not only that but you want to do it in a way that does not require the app to hardcode it, does not require explicit configuration, nor does it require the parts to somehow ‘tell’ MEF they are the default. Also you don’t want the parts that are importing ILogger to have to know or care about a LoggerManager or anything like that. Instead they should simply have an import of ILogger.

[Export]
public class Executor
{
    [ImportingConstructor]
    public Executor(ILogger logger)
    {
    }
}

The $25000 question is how? The answer is using our friendly ExportProvider. In my last post I described the role of ExportProviders, which is to simply return exports. Those exports can come from several different sources, including from catalogs.

Constructing the container with ExportProviders

If you look on the constructor of the container, you’ll see several overloads which accept an ExportProvider.

public CompositionContainer(params ExportProvider[] providers);public CompositionContainer(ComposablePartCatalog catalog, params ExportProvider[] providers);  

Any export providers passed in to the container are incorporated into the container’s query strategy. This means whenever anyone pulls on the container for an export, these providers will also get queried. Now catalogs have a special provider associated with them called a CatalogExportProvider. As a matter of fact the overload on the container that accepts a catalog is really just syntactic sugar. Behind the scenes we immediately create a CatalogExportProvider passing in the catalog. This means you can pass in an additional default catalog. If you’ve worked with MEF before, you might be shaking your head at this point and thinking “How is this any different than just having an AggregateCatalog and adding two catalogs?” And that IS the key question ;-).

The answer is that adding catalogs to an AggregateCatalog does not allow handling defaults, however using this technique with ExportProviders does. I’ll explain how next.

AggregateCatalogs vs AggregateExportProvider

AggregateCatalog is a catalog that contains a list of catalogs. It is a composite pattern, so querying the parent, queries all the children. This is especially useful when you have parts that are “built in” to the application which are added via an AssemblyCatalog, and other parts which are discovered through a DirectoryCatalog. You can add both catalogs to an AggregateCatalog and everything works nicely. It doesn’t help you though in a default scenario however. The reason is because if one of your catalogs contains your default ILogger and your other catalogs contain the pluggable ILogger implementations, then the aggregate catalog will return them all when it is queried. This means the Executor above will blow up as the constructor is expecting a single ILogger.

For the AggregateExportProvider however, we designed specifically to allow this defaults scenario to be addressed. The provider behaves differently depending on whether it is being queried for a single export or multiple. If the query is for multiple exports, then it works similar to the AggregateCatalog and collects all the exports it finds in any of it’s providers. If on the other hand the query is for a single export, then it uses a prioritization scheme. It will start at the top of the list of ExportProviders and query the first one for the single export (Logger). If it does not find one, then it keeps querying on to the next ExportProvider and so on. Once it finds an ExportProvider that returns one, then it will be returned, if it does not find one, then it will throw an exception.

This means you can have default ExportProviders in the chain (including CatalogExportProviders) that contain your defaults so that the Executor class always succeeds in creation. You can even configure the behavior so that the defaults are overridable or not. For example if you want the default ILogger to always be the logger that is returned for all single import queries no matter what, then put the defaults at the top of the chain. If however you want the default logger to be overridable by another single ILogger, then put it at the end.

Here’s an illustration of what I mean.

public void OverridableDefaults()

{

    var catalog = new DirectoryCatalog(@".\Extensions");

    var defaultCatalogEP = new CatalogExportProvider(new DirectoryCatalog(@".\Defaults"));

    var container = new CompositionContainer(catalog, defaultCatalogEP);

    defaultCatalogEP.SourceProvider = container;

}

In the configuration above, we are placing our defaults at the end of the chain of providers. Remember as  I mentioned above that the ‘catalog’ reference will get wrapped in a CatalogExportProvider as well. It will get added first, followed by the additional providers. We then have to set the SourceProvider to the container, I talked about why this is necessary today in my previous post, though it may be possible for us to infer the setting in the future. Anyway, now when a query happens for a single logger, the container will first check the parts in the Extensions folder, and if none are found it will revert to the defaults.

public void NonOverridableDefaults()

{

    var defaultCatalog = new DirectoryCatalog(@".\Defaults");

    var catalogEP = new CatalogExportProvider(new DirectoryCatalog(@".\Extensions"));

    var container = new CompositionContainer(defaultCatalog, catalogEP);

    catalogEP.SourceProvider = container;

}

In this example, we are passing in the default catalog first, and then passing the catalog (as an EP). This configuration now means that the defaults are NEVER overridable, as whenever the container is queried for a single logger, it will ALWAYS return the default.

Using Type or Assembly Catalogs for defaults

Now in the approach above we are using DirectoryCatalogs for specifying defaults. But remember, this is an option, you don’t have to, and in many cases might not want to. For example you might want to just specify your list of defaults in code, or even in a config file. TypeCatalog provides a great way to do this. (It accepts a params of Types, so you can add as many as you want).

public void OverridableDefaultsWithTypeCatalog()

{

    var catalogEP = new CatalogExportProvider(new DirectoryCatalog(@".\Extensions"));

    var defaultCatalogEP = new CatalogExportProvider(new TypeCatalog(typeof (ILogger)));

    var container = new CompositionContainer(catalogEP, defaultCatalogEP);

}

OK, so now that you sold me, what are the caveats?

As with all things, there are some. Really, I can only think of one primary one, and that is that there’s still a bit of indeterminism as to what will get returned on a single import depending on how you set up the provider chain. If you go with the approach of putting defaults first, then it is completely deterministic. You know that whenever a single import request is issued to the container, the exports in that catalog will be returned, period. If however you arrange the defaults at the end of the chain, then it really depends on what is in the middle. Let’s say you have 3 EPs, and the one in the middle has a part with the single export that you are looking for, while you also have a default. In that case the one in the middle will get returned. Another caveat might be that this does add a bit of complexity, however I would argue that’s a reasonable trasdeoff to having to import collections all over the place.

The code

You can download sample code that illustrates using ExportProviders in various fashions here

If you look inside, you’ll find much more than just what we covered here.  Including how to do do role based composition, or even wire MEF to a configuration store where config info is an import. All of this will get covered at some point.

Additionally:

1. You’ll find several test classes which are using a context/specification style of testing to illustrate how to use ExportProviders.  If you are not familiar with BDD/CS it may seem very foreign, but I think you’ll find it easy to follow once the initial shock wears off. Having gone through this experience made me a big fan of CS style, and that is for another post.
2. You’ll find several test helper classes I’ve written specifically for MEF. These are really useful for folks writing their own ExportProviders and who wish to mock / fake certain parts of our programming model. Specifically I am talking about FakeExportDefinition and FakeExportProvider. Additionally you’ll see some common classes I’ve used for my own CS experiments.

For stuff relating to what was covered in this post, go check out the Import_Logger_Specs.cs unit-tests.

Special thanks to Scott Bellware as well as Scott C. Reynolds and David Foley who invested a lot of time and effort in getting me off the ground in using this style of testing. Without their help, I would have been stranded in a pool of confusion. This post is really not doing CS justice, and I really need a separate series. I can’t guarantee that I’ll get to it, but I’ll try.

What’s next

In the next post we’ll talk about establishing parent-child containers hierarchies. You may be asking how does this relate to ExportProviders? I’ll leave you with this thought to ponder, our container IS an ExportProvider.

“View Model” - the movie, cast your vote.

http://www.flickr.com/photos/richardmoross/3064808115/

No we’re not actually making a movie about View Model. If we were I am sure we’d get a low turn-out. :-) However it did get your attention.

What we are doing is some serious exploration into how we can help from a platform perspective folks that are implementing ViewModel (AKA Model-View-ViewModel  AKA Presentation Model)  in their Silverlight and WPF applications.

In the sense of a movie production, we’re in the script-writing phase. Here’s the general background.

Why is ViewModel important?

There have been many a post on the importance of ViewModel as a pattern and the benefits it brings. In that there is little disagreement that it benefits both developers and designers.

For developers it allows them to have clean separation of presentation logic from the UI rendering, thus making the app easier to maintain. It removes code from the code-behind that often makes the UI logic difficult to test.

For designers it provides a way for a designer to completely change the look of the UI in a tool such as Expression Blend, without breaking the application functionality. Furthermore it gives the designer freedoms beyond simple look and feel, to actually decide which data elements are exposed, as well as defining the interactions between the UI elements through commands and attached behaviors.

The debate over roles

Although the benefits of ViewModel are known, there’s quite a lot of debate both inside and outside Microsoft on the roles the developer and designer play in developing applications that use the pattern.  This runs the spectrum from the designer having complete control of every aspect of the UI,  to the development team having more of a tight handle on the UI components, and the designer being responsible for skinning. In either case there are tradeoffs.

What is important to you?

What is your experience with ViewModel today?

1. Where does the platform help,? Where does it hinder?
2. What can we do in the platform to make life easier?
3. What role do developers / designers play in your application of ViewModel.

Like any movie, we need to touch on the right nerves in order to make it a box-office hit. We need your feedback so we can complete the script.

Thanks for your help

MEF Preview 5, changes and enhancements

We recently shipped MEF preview 5 on Codeplex, an exciting release.

In the latest release, you’ll find we’ve made quite a few changes, and some really powerful enhancements to our previous codebase. In this post, I’ll talk about those changes in detail, and why we made them. I’ll also discuss some changes we will be making in the future, in order to give you a heads up, so that you can adjust your code bases now.

Throughout the development of preview 5, we’ve done our best to minimize the impact to you. There are some breaking changes, primarily in terms of namespace refactoring, most of which do not effect part authors, but will effect MEF hosters, and authors of custom programming models or export providers.

Here’s a summary of these changes for those who want to just cut to the chase. For those who want the full skinny, that comes after the summary.

MEF Studio

MEF Studio is a designer hosting sample. It has an IDE that hosts various designers like Windows Forms, UserControl, etc. One can add controls on to these designers from the toolbox, set properties using the property grid, view generated code, etc. It provides design time experience for the designers and has extension points for extending the adding custom parts.

Migrating from preview 4

When you upgrade your existing apps, you will likely run into a few issues. Wes put together the following useful list of common errors that you might run into when migrating.

• System.ComponentModel.Composition.Container does not exist -> Add reference to System.ComponentModel.Composition.Hosting namespace
• CompositionContainer does not container method AddPart or Compose -> Need to start using CompositionBatch, or one of the helper extension methods ComposeParts or ComposeExportedObjects
• CompositionOptionsAttribute does not exist -> For CreationPolicy use PartCreationPolicyAttribute
• INotifyImportCompleted does not exist -> Use IPartImportsSatisfiedNotification interface and change method from ImportCompleted to OnImportsSatisfied

Part Lifetime changes

Previously, the CreationPolicy property of the CompositionOptions attribute was used to declare a part’s lifetime. We found this was less discoverable for customers as they have to know about the existence of the attribute. We also found that CreationPolicy was ambiguous in name, as it does not make clear whether or not the policy applies to the part or the export.

With the new changes, you will use the new PartCreationPolicyAttribute. CompositionOptions has been removed. Having part in the name of the attribute makes it easier to discover, and also removes ambiguity as to it’s scope.

Below the Logger class is declared as shared:

[PartCreationPolicy(CreationPolicy.Shared)]
[Export(typeof(ILogger))]
public class Logger : ILogger
{
}

Part Discovery / Inheritance

In MEF Preview 4, a part by default would be discovered if there was an export on the most derived class. Additionally a part author could decorate the part with the CompositionOptions attribute, and set the DiscoveryMode property to change the behavior. Regardless of which mode was chosen, we would always look at all exports in the inheritance chain and discover them once we determined a part was a part.

We heard quite a bit of feedback both internally and externally around both the naming of the different enum values for DiscoveryModel, and the resulting behavior.

Default Behavior

By default we will only look only at the most derived type to discover exports. If exports are found, then we will do a deep dive to discover all imports wherever they live in the hierarchy, including interface members. This is because imports are an implementation detail of a part, and the part many not function without them.

In the example, we will discover a single export of IOrderScreen, and the OrderList import.

[Export(typeof(IOrderScreen))]
public abstract class OrderScreen : IOrderScreen
{
 [Import]
 public IOrderListView OrderList { get; set; }
}

[Export(typeof(IOrderScreen))]
public class NorthwindOrderScreen : OrderScreen
{
}

Below, we will not discover anything, as the export is on the base.

[Export(typeof(IOrderScreen))]
public abstract class OrderScreen : IOrderScreen
{
}

public class NorthwindOrderScreen : OrderScreen
{
 [Import]
 public IOrderListView OrderList { get; set; }
}

Inherited exports behavior – using the PartExportsInheritedAttributed

The PartExportsInherited attribute allows declaring on a base class or an interface that it’s exports should be discovered by inheritors / implementers. This replaces the previous [CompositionOptions(DiscoveryMode = DiscoveryMode.Always)]. This basically allows you to define a template for a part, and is useful hiding MEF’s implementation details from a part author. Implementers can further extend on what has been provided, such as adding their own exports and imports.

There’s a few guidelines / caveats to using this feature.

• PartExportsInheritedAttribute only makes the exports of the type it decorates discoverable by inheritors. It does not make exports of derivers of that type discoverable. The deriver itself needs to be decorated in order to make its exports discoverable.
• We will ignore loose ExportMetadata attributes (and custom metadata attributes) that do not have an associated export.
• If an inheritor overrides a member from the base which has an export, and decorates the overridden member with an export, two exports will be discovered, even if the contract names are the same. This means if you expect implementers to add their own metadata, this might not be the best option, or at least you will need to provide special handling. We are looking into changing this behavior to have the inheritor override rather than be additive.

In the example below, NorthwindOrderScreen will automatically export IOrderScreen.

[PartExportsInherited]
[Export]
public interface IOrderScreen
{
}

public class NorthwindOrderScreen : IOrderScreen
{
}

Below NorthwindOrderScreen exports 2 instances of IOrderScreen, one with metadata and one without. The explicit export of IOrderScreen by NorthwindOrderScreen is in addition to the existing export.

[PartExportsInherited]
[Export]
public interface IOrderScreen
{
}

[ExportMetadata("Customer", "Northwind"]
[Export(typeof(IOrderScreen))]
public classNorthwindOrderScreen :IOrderScreen
{
}

Ignoring part discovery – Using the PartNotDiscoverableAttribute

This attribute replaces replaces [CompositionOptions(DiscoveryMode.Never).  It is useful for when a part author has parts that they do not want to be automatically discovered by catalogs and .  The scenarios where this make sense are where you either have a part which you will manually compose outside of a catalog, or you have a part that you intend for inheritors to use in a catalog but which cannot be made abstract.

In the sample below,  class OrderScreen will be ignored by the catalog. However, when class NorthwindOrderScreen is scanned, we will discover IOrderScreen, and will satisfy the OrderList import.

[PartNotDiscoverable]
[PartExportsInherited]
[Export(typeof(IOrderScreen))]
public class OrderScreen : IOrderScreen
{
 [Import]
 public IOrderListView OrderList { get; set; }
}

public class NorthwindOrderScreen : OrderScreen
{
}

Changes to collection imports

ImportMany attribute

We’ve added a new [ImportMany] attribute. This attribute is to be used for specifying that an importer is expected to import all parts that match the contract. This attribute is equivalent to using [Import] on collections today. By our next release however, [Import] will change to mean import an exported collection.

Once we make the switch, the [ImportMany] attribute will be required on both properties and importing constructor parameters in order to get the same behavior as today.

As an example let’s take an importer of a collection of IOperation contacts.

With the new build the following will have identical results.

[Import]
public IEnumerable<IOperation> Operations { get; set; }

[ImportMany]
public IEnumerable<IOperation> Operations { get; set; }

In the next drop,  the behavior of the first will change. Instead of importing all exports of IOperation, it will instead be looking for an exporter of IEnumerable<IOperation>. The main reason for this is to support custom collections. Today for example the following code won’t yield the expected results if IRepository<T> is an ICollection<T>.

[Import]
public IRepository<Customer> Customers { get; set; }

What the part author is intending here is to import a repository of customers. The repository as a whole is the import. Instead what will happen today is the container will set Customers to a new instance of Repository<Customer>. It will then query for all the Customer exports and add them to the Repository.

Array imports

In this release we’ve added support for array imports.  This allows the following syntax to be supported.

[ImportMany]
public IOperation[] Operations { get; set; }

Future Deprecation of ExportCollection<T> and ExportCollection<T,M>

In the next preview (not this one) we will be removing ExportCollection from MEF. The reasoning is that ExportCollection does not introduce any additional functionality, and we don’t want to introduce a collection which is solely there for syntactic sugar. The alternative recommended syntax for doing ExportCollection will be to use the new array support. Using the new syntax is significantly more compact than using ExportCollection, and is also less cryptic as arrays are very clear as to how they function.

[ImportMany]
public Export<IOperation>[] Operations { get; set; }

[ImportMany]
public Export<IOperation, IOperationMetadata>[] Operations { get; set; }

Additionally we support custom derived collections, thus you can easily create your own collections that provide the sugar.

Typed Import/Exports

In Preview 4, MEF discovers exports based on contract name, and not based on the type of the exporter. This means that an export can actually have an incompatible type with the importer. At the time when the export is set on the import, if the cast fails, then an exception is thrown.

This new feature in Preview 5 enables MEF to match imports and exports on contract AND type. When a part imports a contract, it additionally specifies the specific type that it is looking for. Only those exporters that also match on the importer type are matched. This means instead of failing, if the exporter’s type is incompatible, then it will not be matched.

In most cases, the type specification is done implicitly, and does not require any work on the part of the part author. The overloads of Export and Import that used to take Type as param, will now in addition to converting to the string contract representation, also embed the type information.

For example the code below works as it would have before.

[Export]
public class Editor
{
 [Import]
 public ISpellChecker SpellChecker { get; set; }
}

[Export(typeof(ISpellChecker))]
public class SpellChecker : ISpellChecker
{
}

However code that uses pure string contracts, will yield a different result than it would have before. The SpellChecker below will not be imported into the Editor.

[Export]
public class Editor
{
 [Import("SpellChecker")]
 public ISpellChecker SpellChecker { get; set; }
}

[Export("SpellChecker")]
public class SpellChecker : ISpellChecker
{
}

[Export("SpellChecker",typeof(ISpellChecker))]
public class SpellChecker : ISpellChecker
{
}

[Export]
public class Editor
{
 [Import("EditorContracts.SpellChecker",typeof(object))]
 public EditorContracts.ISpellChecker SpellChecker { get; set; }
}

public delegate bool ValidatorDelegate<T>(T value);

public class CustomerValidator
{
  [Export(typeof(ValidatorDelegate<Customer>))]
  public bool Validate(Customer customer)
  {
    return customer.Name != null && customer.Name != String.Empty;
  }
}

[Export]
public class CustomerView
{
  [ImportingConstructor]
  public CustomerView(ValidatorDelegate<Customer> validator)
  {
  }
}

public class Application
{
  private DirectoryCatalog catalog;

  //triggered by the user clicking the Refresh button on the addins page
  public void Refresh()
  {
    catalog.Refresh();
  }
}

Removal of caching / new infrastructure

We found several issues with our previous caching design which was black box. We’ve completely removed the old caching apis. We’ve added in a new API that can be used for caching, however we are not including a default caching implementation within MEF itself. We will however be shipping a caching API sample which illustrates how to use the APIs. The new APIs provides the further benefit of making it much easier to build new programming models that utilize reflection for are reflection based.

We’ve now introduced a new set of classes in System.ComponentModel.Composition.ReflectionModel that can be used by cache implementers. ReflectionModelServices provides a set of static helper methods that can be used for manufacturing part definitions from a cache store.