After my last post about MEF + Factories, I was chatting with Glenn Block (PM for MEF) about my approach. One of the first things he mentioned is why I hadn't used an ExportProvider. As you know, ExportProvider's are new in the latest drop, and provide an interception point for resolving an import to an export.

Taking a look back at the documentation on ComposablePart, I can see why Glenn mentioned this. In it, it states that a ComposoblePart must adhere to to Import/Export contracts. If you've looked at the prior example, you'll see that I'm explicitly violating that rule as I'm finding interfaces based on a base interface, not by Export! At this point, my mind started churning - mainly because there's not a lot of examples or descriptions of what an ExportProvider actually is - but because I wanted to do things "correctly" according to the framework provided. (As an aside, Glenn stated that a "What is an Export Provider" post or documentation is coming, maybe this'll boost that necessity!) What I ultimately came up with was a much cleaner solution than using a FactoryPartCatalog.

Introducing FactoryExportProvider:

   1:  public class FactoryExportProvider<T> : ExportProvider {

   2:     public FactoryExportProvider(Func<Type, T> resolutionMethod) { }

   3:     public FactoryExportProvider(Assembly assembly, Func<Type, T> resolutionMethod) { }

   4:     public FactoryExportProvider(IEnumerable<Type> types, Func<Type, T> resolutionMethod { }

   5:  }

What you'll see is again, it's very straight forward and provides a clean implementation in usage, just as the part catalog example did. Each constructor does just as it had done in the part catalog, so I'll not explain that again. One thing that I discussed with Glenn about was, is it appropriate to look for certain types within an Export Provider? His response was "absolutely you can do that". good, I think I've found the correct implementation, both from less code/object graph standpoint, but also from an intention standpoint.

Internally, the code is very simplistic. Since I'm finding these interfaces on-the-fly, and need more information than just the contract name, I needed to use a FactoryExportDefinition to store this information. I've you've looked at the prior example, you'll see this came back out of necessity.

   1:  public class FactoryExportDefinition<T> : ExportDefinition {

   2:     public FactoryExportDefinition(string contractName, Type type, Func<Type, T> resolutionMethod) { }

   3:   

   4:     public override string ContractName { get { ... } }

   5:     public Type ServiceType { get; private set; }

   6:     public Func<Type, T> ResolutionMethod { get; private set; }

   7:  }

When finding all of the interfaces that implement the base interface specified in the FactoryExportProvider, I convert those into a list of FactoryExportDefinition objects. Reason being, is that the export provider compares an ImportDefinition to an ExportDefinition when finding all available exports. This comparison is done by implementing the GetExportsCore method. The idea of export providers, is that when resolving all dependencies, MEF will call into all of the registered ExportProviders to determine if they can supply the Export and will do a bunch of cardinality matching for you. Out of the box, MEF provides an export provider for it's registered part catalogs. Here's the FactoryExportProvider's implementation of GetExportsCore.

   1:  protected override IEnumerable<Export> GetExportsCore(ImportDefinition importDefinition) {

   2:     IList<Export> exports = new List<Export>();

   3:     var constraint = importDefinition.Constraint.Compile();

   4:     var foundExports = from d in definitions

   5:                        where constraint(d)

   6:                        select new Export(d, () => d.ResolutionMethod(d.ServiceType));

   7:   

   8:     if (importDefinition.Cardinality == ImportCardinality.ZeroOrMore)

   9:        exports = foundExports.ToList();

  10:     else if (foundExports.Count() == 1)

  11:        exports.Add(foundExports.First());

  12:   

  13:     return exports;

  14:  }

It's that simple. The Export's that are returned will have the resolution method called when the actual object is needed. When it comes down to including this within your application, it's just as easy as it was for the part catalog, you just register things a bit differently.

   1:  public interface IService { }

   2:  public interface IUserService : IService { }

   3:   

   4:  [Export]

   5:  public class UserController {

   6:     [ImportingConstructor]

   7:     public UserController(IUserService userService) { }

   8:  }

   9:   

  10:  // in your application

  11:  private void Compose() {

  12:     var catalog = new AttributedAssemblyPartCatalog(Assembly.GetExecutingAssembly());

  13:     var factoryProvider = new FactoryExportProvider<IService>(GetService);

  14:     var container = new CompositionContainer(catalog, factoryProvider);

  15:     container.AddPart(this);

  16:     container.Compose();

  17:  }

  18:   

  19:  public IService GetService(Type type) { return ... }

And that's it. Ultimately, this leads to a cleaner implementation that uses less types that you have to manage, and, adheres to the correct intentions of the framework. Much thanks to Glenn who I chatted with for several hours last night! You can get the downloadable source here. Enjoy!

Lately I've been really digging into MEF and have been looking at it's pros & cons, ease of use, extensibility, and the simple DI container that it can provide. I'm not going to give an overview of MEF, as others have done so already. What I am here to show off is a concept that may prove useful for some applications. Many of us use a DI container in very simplistic ways, as well as registering injection strategies during type resolution. If you have no needs of this latter, MEF is very simple and easily fits into your current architecture by not having to change anything but decorating things. For example:

   1:  public interface IUserService { }

   2:   

   3:  [Export(typeof(IUserService))]

   4:  [CompositionOptions(CreationPolicy = CreationPolicy.Factory)]

   5:  public class UserService : IUserService { }

   6:   

   7:  [Export]

   8:  public class UserController {

   9:     [ImportingConstructor]

  10:     public UserController(IUserService userService) { }

  11:  }

At MEF's simplistic nature, you see that during construction, our exported services are being imported for us, but only because we don't care about it's construction and assume that generic construction will work. So when we call resolve UserController using MEF, it'll create and inject a new instance of UserService for us.

Now, say we have a need where the construction of IUserService needs to go through a factory. For instance, maybe IUserService is a WCF endpoint, and you have custom logic built into properly constructing the proxy endpoint. Well, MEF can solve this issue for you by exporting methods, but what you have to do is ultimately change your code and have 2 constructors.

   1:  public interface IUserService { }

   2:   

   3:  // in your application

   4:  [Export(typeof(IUserService))]

   5:  public IUserService ConstructUserService() { return ... }

   6:   

   7:  [Export]

   8:  public class UserController {

   9:     [ImportingConstructor]

  10:     public UserController([Import(typeof(IUserService))] Func<IUserService> serviceMethod)

  11:         : this(serviceMethod())

  12:     { }

  13:   

  14:     public UserController(IUserService userService) { }

  15:  }

As you can see, it's not that nice. We need both constructors because one is used in production and one is used for testability. It ultimately leads to a lot of confusion as to why we need it. So, with that in mind, I set out to determine how this pattern could be achieved using MEF, but also provide a seamless transition from a DI world to MEF. Enter, FactoryPartCatalog:

   1:  public class FactoryPartCatalog<T> : ComposablePartCatalog {

   2:     public FactoryPartCatalog(Func<Type, T> resolutionMethod) { }

   3:     public FactoryPartCatalog(Assembly assembly, Func<Type, T> resolutionMethod) { }

   4:     public FactoryPartCatalog(IEnumerable<Type> types, Func<Type, T> resolutionMethod) { }

   5:   

   6:     public override IQueryable<ComposableDefinition> Parts { get { return ... } }

   7:  }

When we use this in our application, it brings back the simplicity of MEF. What it's doing during construction is looking through the assembly (first two constructors) to find all interfaces that implement type T. The interfaces that it finds will be created into ComposablePart's for MEF's container to utilize. Ultimately, when GetExportedObject<T> is called, it'll execute the resolution method you specified passing in the Type that was requested.

As you can see below, we're using a AggregatingComposablePartCatalog adding our new FactoryPartCatalog and AttributedAssemblyPartCatalog. We've told FactoryPartCatalog to look through the current assembly for all interfaces that derive from IService. Upon construction injection by MEF, it'll find that it's requesting an export of IUserService, find it in the FactoryPartCatalog, and call GetService(Type) to get it's instance.

   1:  public interface IService { }

   2:  public interface IUserService : IService { }

   3:   

   4:  [Export]

   5:  public class UserController {

   6:     [ImportingConstructor]

   7:     public UserController(IUserService userService) { }

   8:  }

   9:   

  10:  // in your application

  11:  private void Compose() {

  12:     var catalog = AggregatingComposablePartCatalog();

  13:     catalog.Catalogs.Add(new AttributedAssemblyPartCatalog(Assembly.GetExecutingAssembly()));

  14:     catalog.Catalogs.Add(new FactoryPartCatalog<IService>(GetService);

  15:     var container = new CompositionContainer(catalog);

  16:     container.AddPart(this);

  17:     container.Compose();

  18:  }

  19:   

  20:  public IService GetService(Type type) { return ... }

Now, there's a lot more code behind the scenes that is required to get a new Part Catalog up and running, but I'll leave that for you to check out in the downloadable source. As this is purely a proof of concept, I'm sure there's more simplifications or additions that can be added, but for getting this running out of the box in this manner, it works great!