MEF and more

MEF’s Convention model

hammett [MSFT] — Wed, 09 Mar 2011 02:51:28 GMT

In the last drop of MEF on codeplex we introduced a handful of interesting features. One of them – which has a large API surface – is the new registration mechanism. It allows you to accomplish interesting things:

Define a predicate (rule) that will cause all matching types to be exported as MEF parts
Export types that you do not have access to the source code
Bridge an existing plugin model – say, FxCop’s – to MEF’s API

Using it is quite simple. Suppose you have the following types in a project:

    public interface IController
    {
    }

    public class AccountController : IController
    {
    }

    public class HomeController : IController
    {
    }

You can then decide the export AccountController and HomeController based on something they share: they both implement IController. (Additionally, they both are concrete classes whose type name ends with ‘Controller’, and you could also define a rule based on this).

using System;
using System.ComponentModel.Composition;
using System.ComponentModel.Composition.Hosting;
using System.ComponentModel.Composition.Registration;

class Program
{
    static void Main(string[] args)
    {
        var registration = new RegistrationBuilder();

        registration.Implements<IController>().
            Export<IController>();

        var catalog = new AssemblyCatalog(
            typeof(Program).Assembly, registration);
        var container = new CompositionContainer(catalog);
    }
}

So we build a RegistrationBuilder and tell it to get all types that implement IController, and export those types with the IController contract.

Note though, that the RegistrationBuilder is _not_ a catalog. It is passed to a catalog – in the example above, an AssemblyCatalog. So the universe of types applicable to this RegistrationBuilder is limited to the set of types that this AssemblyCatalog can “discover”.

If you’re unsure it’s working, you can set a breakpoint in your code and investigate the Parts property of the catalog. It should have two “Parts”: HomeController and AccountController, both exporting a single contract: IController.

Exporting Self

We could make a small change to have them exporting more than the IController contract.

        registration.Implements<IController>().
            Export().
            Export<IController>();

The single .Export will cause the type to be exported as “itself”. It’s the equivalent of just adding a [Export] attribute to a type, whereas the other line – Export<IController> – is the equivalent of [Export(typeof(IController))]

Configuring the export

You’d also notice that some of the API takes an optional configuration instance wrapped in an Action delegate. Export() takes ExportBuilder. Import() takes ImportBuilders. You can use it to add more stuff to the Export/Import such as metadata.

            registration.Implements<IController>().
                Export(config => config.AddMetadata("name", t => t.Name)).
                Export<IController>();

Where’s the convention?

Interesting question. Our piece of code will select all types matching the predicate (in this case, Implements<> is a shortcut to a predicate). We don’t know how many will match: 1, 2, 100 controllers? Who knows?

It’s not reasonable to think that all these controllers would look the same. First and foremost, some are bound to use constructors. What should you do?

Well, nothing. By convention our RegistrationBuilder will select the constructor with most parameters. Also, if something looks like a collection, it will change the import cardinality to Zero or Many – which is the equivalent of using the [ImportMany] attribute.

Sweet, isn’t it?

Bypassing the convention

What if? What if you want to use a different constructor for a specific controller? What if a controller happens to have two constructors with the same number of arguments?

In this case, reject the convention by being explicit. Suppose your AccontController looks like the following:

public class AccountController : IController
{
    private readonly IMembershipProvider _provider;
    private readonly IAuthentication _auth;

    public AccountController(IMembershipProvider provider)
    {
        _provider = provider;
    }

    public AccountController(IAuthentication auth)
    {
        _auth = auth;
    }
}

In this case, add the following registration code specifically to the AccountController. Notice that it selects the constructor based on a Expression<>. We thought this is great as it’s refactor-friendly.

    registration.OfType<AccountController>()
        .SelectConstructor(builder => 
            new AccountController(
                builder.Import<IMembershipProvider>()));

The first parameter your lambda takes is a ParameterImportBuilder. Its Import methods allows you to further configure the import as well..

Explicit wiring

This is a recurring question: “I have two Foo’s. My piece of code imports just one. Mef blows up. What should I do?”

MEF rightfully throws an exception in this case, since it cannot tell which Foo it should give to the importer of a single one. But what to do about it? Well, building on our last example, imagine that AccountController takes a single IAuthentication instance, but you have two available:

    registration.OfType<DummyAuth1>()
        .Export<IAuthentication>();
            
    registration.OfType<DummyAuth2>()
        .Export<IAuthentication>();
        
    ...
    
    public class AccountController : IController
    {
        private readonly IAuthentication _auth;

        public AccountController(IAuthentication auth)
        {
            _auth = auth;
        }
    }

Our solution to this problem is to “name” an specific export and then use this “name” on the import side as well.

    registration.OfType<DummyAuth1>()
        .Export<IAuthentication>(
           builder => builder.Named("my_1"));
            
    registration.OfType<DummyAuth2>()
        .Export<IAuthentication>();

    registration.OfType<AccountController>()
        .SelectConstructor(builder => 
            new AccountController(
                builder.Import<IAuthentication>(
                    config => config.Named("my_1"))));

This was a quick overview of this feature. There’s more to come, let me know what you’d think.

MEF Gems 2 of many: Collections

hammett [MSFT] — Thu, 28 Oct 2010 21:27:22 GMT

So in the previous gem I went over the differences between import and import many. Now let’s consider the different ways to import many dependencies.

Check this piece of code:

    [InheritedExport]
    abstract class Foo { }

    class Foo1 : Foo { }
    class Foo2 : Foo { }
    class Foo3 : Foo { }

So here we have a single contract and three exports just to make volume and test the collection imports. The first way you’d think of importing them would be using IEnumerable<Foo>:

    [Export]
    class ImportsOfCollections
    {
        [ImportMany]
        public IEnumerable<Foo> Foos { get; set; }
    }

And this works. Note that MEF will instantiate an implementation of IEnumerable<T> and set the property. This is the default behavior for this type.

Another way you may consider is a standard array:

    [Export]
    class ImportsOfCollections
    {
        [ImportMany]
        public Foo[] FoosArray { get; set; }
    }

This option also leaves to MEF the instantiation of the array type.

Now, a different way would be using ICollection<T>:

    [Export]
    class ImportsOfCollections
    {
        [ImportMany]
        public ICollection<Foo> FoosColl { get; set; }
    }

In this case, if you run this code you’ll get an error. That’s because MEF doesn’t know which implementation of ICollection you want. It expects you to take care of that. Easy fix:

    [Export]
    class ImportsOfCollections
    {
        public ImportsOfCollections()
        {
            FoosColl = new List<Foo>();
        }

        [ImportMany]
        public ICollection<Foo> FoosColl { get; set; }
    }

And now it will work as expected. This allows you to use anything that implements ICollection<T> including ObservableCollection<T>.

Behavior on recomposition

What would happen to my collections if a recomposition is triggered? It depends.

If MEF owns the collection instance, it would supply your components with new instances. Otherwise, it will call .Clear and .Add as many time as needed to repopulate the collection.

In other words, for IEnumerable<> and Array, MEF will supply a new instance to the property. For ICollection<> implementations, it will call .Clear and .Add.

MEF Gems–1 of many: Import vs ImportMany

hammett [MSFT] — Mon, 27 Sep 2010 22:35:25 GMT

Phew! We’ve been working hard! I’m planning to put another Codeplex drop soon so you can see and test the changes, and of course, share your feedback. Also looking forward to run a usability test – let me know if you’re in seattle/redmond area and if you’re willing to participate!

If you’ve been using MEF for a while you have stumbled upon [ImportMany] and are probably using it often. What you probably don’t know is the complete story on how MEF handles collections.

What’s the difference between Import and ImportMany?

Underneath, MEF translates everything into ImportDefinition and ExportDefinition. ImportDefinition carries a cardinality: “zero or one”, “exactly one” or “zero or more”. When using the Import attribute you can either define zero or one or exactly one, which leaves one out.

Consider the following:

[Export] Plane : ITransportSystem

[Export] Car : ITransportSystem

[ImportMany] IEnumerable<ITransportSystem>

You can safely guess what you will get, right?

The following is also interesting:

[Export] IEnumerable<ITransportSystem>

[Import] IEnumerable<ITransportSystem>

Some people ask for an aggregation:

[Export] Plane : ITransportSystem

[Export] Car : ITransportSystem

[ExportMany] IEnumerable<ITransportSystem>

// (Plane + Car + AllItems from previous one)
[ImportMany] IEnumerable<ITransportSystem>

But we don’t support this one…

So ImportMany is a way to express that you want to import all “items” into a type capable of exposing many items (usually IEnumerable).. Next one I’ll explain more about this purposely vague last statement

Container hierarchies in MEF: shaping it for the future (maybe)

hammett [MSFT] — Thu, 09 Sep 2010 22:42:00 GMT

Recapping: MEF supports two creation policies: shared (think singleton) or non-shared (think transient, prototype or a fancy new operator). MEF also recognizes types that implement IDisposable and correctly “implement the protocol” for calling Dispose on them in the right time.

This is all goodness, but as applications grow in complexity, this is hardly enough. You can imagine a MDI application that wants distinct singleton instances for each document. That’s actually why we decided to use the name Shared instead of Singleton. A component is shared within a context. Another historical fact is that in the early days, MEF’s container used to be called CompositionDomain. Thinking about, I believe it was the perfect name:

Each “domain” represents an isolated island of components and their wirings (composition)
Each “domain” holds ownership of components it instantiates
Each “domain” reclaim resources off what it owns once it is disposed
Optionally, a “domain” can be linked to a parent domain, so dependencies can be fulfilled by components owned by the parent

The last bullet leads to an important compromise: hierarchy must be established in a way that the depth means shorter lifetime. In other words, the top level container must be the one that lives the longest, and the bottom container the one that lives the shortest. If you change this, hell breaks loose.

For some reason the class was renamed (before I joined the team) to CompositionContainer, but the principles remain. They allow you to support requirements such as the typical “a container per-web-request” or “multi-tenancy” where each container represents customizations for each tenant, and finally MDI apps where each document means a new container; to name just a few.

To surprise some of you, we have always supported containers hierarchy in MEF. The API were always there:

var parent = new CompositionContainer(catalog);

var child = new CompositionContainer(parent);

Unfortunately, the above doesn’t accomplish much. The only way for MEF to discover components is through catalogs. So in order to control what each container will own you have to manage the catalogs accordingly, and specify the right ones when creating containers:

var parent = new CompositionContainer(globalCatalog);

var child = new CompositionContainer(childCatalog, parent);

But the vast majority of applications start with a single catalog, say DirectoryCatalog. What to do in this case?

Aware of this, I published a FilteredCatalog sample code on Codeplex. While it helps, it is still hard to get filtering right.

The problem in practice

For the next release we are considering several options to free – or at least diminish – the pain for users of MEF who need container hierarchies in order to get “scoping”. As most of the pain is based on how to deal with catalogs, we are currently focused on those. Note that this is a hard problem and we may reject all options and table this for yet another release. :-\

Say you’re writing a MVC app using MEF. You also want controllers and related artifacts to be isolated in a per-web-request basis. Your starting point is a catalog that has everything plus the kitchen sink. You need to select only the components that should be in the request level container. How would you do it?

Components (parts in the MEF lingo) have exports – remember the [Export]?
Each controller is likely to export IController
Nailed it!

var catalog = new DirectoryCatalog(binFolder);

var perRequestCatalog = catalog.Where( component -> component.Exports<IController>() );

This looks sufficient, right? The perRequestCatalog contains all components that happen to export IController.

What to do next? So far you have two pieces of information in the form of sets: the catalog, which is a DirectoryCatalog and contains everything (including the controllers) and a perRequestCatalog which contains all controllers.

Your gut reaction may be to write the following:

var catalog = new DirectoryCatalog(binFolder);

var perRequestCatalog = catalog.Where( component -> component.Exports<IController>() );

var parent = new CompositionContainer(catalog);

...

var perRequestContainer = new CompositionContainer(perRequestCatalog, parent);

Looks reasonable, right? Except that it’s wrong wrong wrong… Now the parent container points to a catalog that has everything, and the perRequestContainer has just the catalogs. If you ask the latter for all controllers, guess what will you get? All controllers. Twice.

To fix that the parent container should point to a catalog that has everything BUT the controllers. So this is a general rule for scoping in MEF, you usually won’t want overlapping sets unless you know what you’re doing.

Going back to code, imagine we could write the following:

var catalog = new DirectoryCatalog(binFolder);

var catalogPair = catalog.Where( component -> component.Exports<IController>() );

var perRequestCatalog = catalogPair.Matching;

var appLevelCatalog = catalogPair.Unmatching;

Now the .Where call returned two sets: the true and the false. The false set happens to be the input set minus the true set, aka the difference, aka the complement. With that it’s easy to get it right:

var parent = new CompositionContainer(appLevelCatalog);

...

var perRequestContainer = new CompositionContainer(perRequestCatalog, parent);

Now you will get the expected behavior, since the sets do not overlap.

Shaping it

Then it comes to how to expose it. We’re exploring a number of ways. First, let’s break it in three correlated APIs:

Filter the catalog based on a predicate - method name?
Hold the true set and the false set - type name?
Expose the false set - property name?

For the first, we are considering: Catalog.Filter, .Partition and .Where. Remember, there’s no clear winner, all options have drawbacks. Filter does not convey that the result is two sets. Partition is quite mathematical, and may not elude that it can also be used for pure filtering scenarios. Where brings the mental model of Linq, but doesn’t return IEnumerable<> so it may be abusing the mental model.

For the second, we’ve been debating over FilteredCatalog, PartitionedCatalog, Tuple<Catalog,Catalog>, and PairedCatalog. Note that the result of the aforementioned method is itself a catalog, but a catalog with “extra” information, the false set.

Finally, for the false set we have considered a property like Complement, PartsNotFiltered, DisjointSet.

Hard! How would you design it?

MEF features for v.next – feedback request

hammett [MSFT] — Fri, 11 Jun 2010 21:55:16 GMT

We’re in planning phase for MEF for quite some time. I believe we have a very decent idea of things that needs improvement, and the priority of those. Of course, our team has limited resources so there are no promises whether we can actually ship any of those in the next MEF release. That said, it would be great if you could weight in and let us know what would you consider more valuable. Pick one or two items that you rather see us not shipping a v.next unless we add those. :-)

Some ideas of features (feel free to suggest more)

- Convention-based discovery catalog
- Explicit wiring
- Generic instantiation (being able to export IRepository<> and import IRepository<Customer>)
- Better diagnostics
- AOP/Interceptors
- Integration with XAML/WPF
- Integration with Azure
- Simplification of scoping/container hierarchy
- Custom lifetimes (per thread, transactional)

Anything I’ve missed?

MEF: What and why

hammett [MSFT] — Sat, 29 May 2010 15:23:57 GMT

So it’s been almost two years working for Microsoft and feels like several years. Not because I was able to accomplish much – I haven’t – but that things go in a different pace here. I learned to understand why that is, and how Microsoft can afford to pay smart people to solve tough problems. MEF is one of them.

As a hardcore developer I’ve always approach projects as the ‘what’ and the feature set. As a PM I learned to have a broader view of things. I’ve also learned to lay down plans and really think through before writing a single line of code, but that deserves another post altogether. It took me quite some time to get past MEF as just a framework and understand where it fits in the bigger picture. I realize, though, that people in community are still asking the wrong questions.

MEF is an IoC Container? That’s undeniable. It makes use of the same Inversion of Control principle that governs all IoC Containers out there. In the past, we tried hard to position it as not an IoC Container, but that was the wrong approach. What we really meant to say was that it’s not comparable to the usual suspects. Instead, it’s a very specialized one. If you want concrete points (applies to MEF out of the box):

· We do not have the same extensibility points

· We do not support manual/explicit wiring

· We do not support any interception mechanism

· We do not have any self-contained reusable extensibility mechanism, such as Windsor’s Facilities

Behavior wise MEF also differs from the usual suspects. We value explicitness over conventions. We value discovery over registration code. We value static analyzability as a mean to support a rich tooling story.

The scenarios

Before saying “you guys suck” please allow me to explain you that MEF – as with most things that come from MS - is scenario-driven. We selected a handful of scenarios for version 1.0 based mostly on partner’s requirements and feedback and it was engineered to meet those. I’ll share a bit about them so you can understand where we came from, and where does MEF fit.

Open ended applications

IoC Containers are really engineered for “closed systems”. You know beforehand the set of components that will make your app, you control how they are wired up (bindings) and their configuration. In an open ended system you just know the set of components you are shipping but once that is deployed and new extensions start to be added, you cross your fingers and hope for the best.

With that in mind, several decisions were made to make MEF a reliable technology for these kinds of scenarios. You certainly don’t want VS to crash if you happen to add a malfunction extension.

Stable composition

Stable composition is a feature introduced to deal exactly with this situation. It tries to pre-compose a graph and rejects pieces that will lead to a part that cannot be set up to its minimum requirements. If you were to use MEF as a standard IoC Container, though, this will eventually bite your development experience, especially if you’re not aware of it.

Reusing “parts” across application models

Imagine writing common parts that you could reuse in a Wpf, Silverlight, Console apps and ASP.NET apps. Of course, this part would have to make some diligence on the kind of dependencies it has from the external world. Any container specific behavior introduced by extension points or optional integrations could hurt this story. If parts were to depend on the container being set up to support a specific feature, then the reuse story would be compromised. That said, I believe it’s fair game to depend or support upon orthogonal/cross-cutting functionality.

Design-time diagnostics

Even though most people dislike MEF’s attributes, it allows us to build a rich tooling story that could help you to write extensions, predict errors and so forth. This is intended a productivity boost, not as a pain-reliever.

Beyond what: why?

Stepping back from the technology, MEF is a great tool for – at very minimum – two reasons:

· It provides a ubiquitous way to expose extension points and consume extensions

· It presents a minimal set of concepts that people should learn in order to deal with extensions

Provided that, in time, the MEF gets the adoption it deserves from framework builders to app builders, we will see an interesting side effect: an ecosystem of extensions with degrees of reusability based on interdependencies. I believe that would be a huge win for us, the .net community, and look forward for this day.

I also believe MEF is a great choice for framework builders. I intend to write a series of blog posts exemplifying this. Keep watching!

MEF and ASP.NET MVC sample updated

hammett [MSFT] — Wed, 15 Jul 2009 21:37:00 GMT

Sample updated to Preview 6. I've also took the time to simplify the MvcCatalog and to hard set the Creation Policy to Non Shared for all controllers.

Have fun!

MEF and ASP.NET MVC sample

hammett [MSFT] — Thu, 23 Apr 2009 20:45:00 GMT

Disclaimer

First things first, don’t consider this sample an official sample. It is just something I’ve created to illustrate some capabilities of MEF when integrated with ASP.NET MVC in the user-level (as opposed to framework level).

Also, if you would try to do this integration yourself, you’ll notice at some point that you’ll need to attach metadata to your controllers, so you can grab the right one on the controller factory. In this sample I provide a custom catalog that is aware of controllers, so it adds the metadata itself saving us the burden. Of course, this adds to complexity..

As MEF targets the extensibility story, this sample is an ASP.NET MVC app that can be “augmented” by new modules. The main app is a shell with almost no functionality. New modules add navigation, controllers, services and consume the services are present on the system.

The first extension module provide adds Wiki support to the main application. The second, a forum module.

Bear in mind that everything is fake. I’m showing how to leverage the extensibilities capabilities of MEF, and not how to design a CMS, Forum or Wiki :-)

In a real world app a similar extensibility mechanism in a web app would also have to deal with database/versioning issues, content resource (additional css, js, images), and so forth.

Download

MvcWithMEF.zip

Walkthrough

You may start by running the app. You should see the following on your browser:

The links above (forum, wiki) were added dynamically by modules loaded.

Where everything starts

The Global.asax.cs holds our bootstrap code:

   1:  protected void Application_Start()

   2:  {

   3:    HostingEnvironment.RegisterVirtualPathProvider(

   4:      new AssemblyResourceVirtualPathProvider());

5:

   6:    RegisterRoutes(RouteTable.Routes);

7:

   8:    var catalog = new CatalogBuilder().

   9:      ForAssembly(typeof(IModuleInstaller).Assembly).

  10:      ForMvcAssembly(Assembly.GetExecutingAssembly()).

  11:      ForMvcAssembliesInDirectory(HttpRuntime.BinDirectory, "*Extension.dll").

  12:      Build();

13:

  14:    _container = new CompositionContainer(catalog);

15:

  16:    var modules = _container.GetExportedObjects<IModuleInstaller>();

  17:    var navService = _container.GetExportedObject<NavigationService>();

18:

  19:    InitializeModules(modules, navService);

20:

  21:    ControllerBuilder.Current.SetControllerFactory(

  22:      new MefControllerFactory(_container));

  23:  }

The first line sets up a custom VirtualPathProvider that check assembly resources for content. Nothing new.

Lines 8-12 defines our catalog, which encapsulates the discovery mechanism on MEF. It also provides us opportunities to customize things. In this case, we want to discover things on the Core assembly (line 9), on the executing assembly/web project assembly (line 10), and anything on the web app’s bin folder that ends with Extension.dll (line 11).

A container is created with a reference to the aggregation of all these catalogs. Right after we retrieve all IModuleInstaller implementations available and start all modules, which is to say we give them a chance to change/add URL routes and add navigation information.

Finally, we create a custom IControllerFactory instance and set up ASP.NET MVC to use it (line 21).

The MEF Controller Factory

   1:  public class MefControllerFactory : IControllerFactory

   2:  {

   3:    private const string ControllerExportEntryName = "controllerExport";

   4:    private readonly CompositionContainer _container;

5:

   6:    public MefControllerFactory(CompositionContainer container)

   7:    {

   8:      _container = container;

   9:    }

10:

  11:    public IController CreateController(RequestContext requestContext, string controllerName)

  12:    {

  13:      var controllerExport = _container.GetExports<IController>().

  14:        Where(exp =>

  15:          exp.Metadata.ContainsKey(Constants.ControllerNameMetadataName) &&

  16:          exp.Metadata[Constants.ControllerNameMetadataName].

  17:            ToString().ToLowerInvariant().

  18:            Equals(controllerName.ToLowerInvariant())).

  19:          FirstOrDefault();

20:

  21:      if (controllerExport == null)

  22:      {

  23:        throw new HttpException(404, "Not found");

  24:      }

25:

  26:      requestContext.HttpContext.Items[ControllerExportEntryName] = controllerExport;

27:

  28:      return controllerExport.GetExportedObject();

  29:    }

30:

  31:    public void ReleaseController(IController controller)

  32:    {

  33:      var export = HttpContext.Current.Items[ControllerExportEntryName] as Export<IController>;

34:

  35:      if (export != null)

  36:      {

  37:        _container.ReleaseExport(export);

  38:      }

  39:    }

  40:  }

This implementation, albeit short, shows interests aspects. First, on the CreateController, we get all exports of IController – which is different from getting all _instances_ of IController. Then, we use the metadata associated with those Exports to find the controller we need to get an instance.

We hold this export instance for the duration of this request (HttpContext.Items), so we can use it on ReleaseController. This relies on the assumption that in a request only one controller is instantiated.

The ReleaseController get back that export instance and calls Container.ReleaseExport, which will go over all the object graph, and properly release and dispose NonShared / Disposable instances. If you miss this step you will be in a route to a memory bloat as every controller is non shared and disposable.

The MVC Catalog

This one is a bit more complex, but remember, it is an optional step. I just added it because I’m lazy and didn’t want to add metadata to every controller (it would be a violation of DRY too.)

public class MvcCatalog : ComposablePartCatalog, ICompositionElement

  private readonly Type[] _types;

  private readonly object _locker = new object();

  private IQueryable<ComposablePartDefinition> _parts;

  public MvcCatalog(params Type[] types)

    _types = types;

  // More constructors //

  public override IQueryable<ComposablePartDefinition> Parts

    get { return InternalParts; }

  internal IQueryable<ComposablePartDefinition> InternalParts

get

      if (_parts == null)

        lock(_locker)

          if (_parts == null)

            var partsCollection =

              new List<ComposablePartDefinition>();

            foreach(var type in _types)

              var typeCatalog = new TypeCatalog(type);

              var part = typeCatalog.Parts.FirstOrDefault();

              if (part == null) continue;

              if (typeof(IController).IsAssignableFrom(type))

                part = new

                  ControllerPartDefinitionDecorator(

                    part,

                    type,

                    type.Name,

                    type.Namespace);

              partsCollection.Add(part);

            Thread.MemoryBarrier();

            _parts = partsCollection.AsQueryable();

      return _parts;

What we’re doing here is: for each type discovered – is a MEF part – we also check if it happens to be a controller. If so, we decorate that part to add an additional export. This export has all the extra metadata that we need to query for that controller later on.

Wiring

As we’re using MEF for extensibility we might just as well use it for typical composition – as long as our requirements are low compared to the use of a full fledge IoC Container.

[Export, PartCreationPolicy(CreationPolicy.NonShared)]

public class ForumController : BasePublicController

  private readonly ForumService _forumService;

  [ImportingConstructor]

  public ForumController(ForumService forumService)

    _forumService = forumService;

  public ActionResult Index()

    ViewData["forums"] = _forumService.GetEnabledForumsRecentActivity();

    return View(ViewRoot + "Index.aspx");

In this controller we import (depend) ForumService, which itself depends on IForumRepository. If you don’t mind the extra noise of attributes, MEF can also cover this aspect of your app – but remember, it wasn’t built to be an IoC Container as the ones out there – more on that in another day.

Conclusion

In the user-level integration MEF plays very well with ASP.NET MVC to enable extensibility on web apps. Of course, this is not the whole story. Like I mentioned, database schema updates/version, making additional content available (js, css, images) and UI Composition are challenging things themselves, but solvable – been there, done that.

With MEF you have one less thing to worry about in this challenging problem space.

Update: Kamil spot the fact that my decorator is leaving out one member, and that essentially makes it ignore the creation policy (which is attached to the part definition, not exports). Sample updated.

Dependencies, ownership and lifetime

hammett [MSFT] — Fri, 17 Oct 2008 01:15:00 GMT

First of all, this blog post contains my own views and does not necessarily reflect the view of employer.

MEF is a complex small project, dealing with a big and complex problem. In our team a feature crew - a PM, dev and tester - owns a feature. We research, brainstorm, prototype to exhaustion, come up with real world scenarios, brainstorm some more and then finally a spec is produced (or finalized). I'm on the lifetime feature crew. Our goal is to decide and propose a solution on how MEF should deal with lifetime.

There is a broad range of possible solutions, from not supporting anything at all (which is a valid option) to support a full extensible (and possibly complex) lifetime story. Things to consider are:

- Being part of the core framework comes with responsabilities. All dogmas should be left on the door, and a solution should be compatible with how the rest of the framework (and its guidelines)
- MEF is not an full fledge IoC, and as such it shouldn't need to behave as one
- The final solution should translate into a predictable behavior for users (more on that below)

The rest of the post is me sharing (with authorization) some of our findings, some of tough calls to make, and kindly asking for feedback :-)

In case you're not familiar, lifetime is a concept widely used on component frameworks, especially IoC containers. However it's not 100% adopted, and it might use different names. It defines the scope of accessibility and how (or better, if) an instance can be shared. Singleton is a common lifetime. So is Transient.

Windsor (and back to Apache Avalon/Excalibur) refers to them as lifestyle instead, and supports Singleton, Transient, Pooled, PerThread and PerWebRequest out of box. It's relatively easy to add a new one. Spring supports Singleton and Transient (which it calls Prototype). The Java version of spring brings extensibility points so you can add new ones. PicoContainer supports only Singletons - new lifetimes can be supported using child container (and carefully registering the components on correctly in the container hierarchy). Autofac supports both singleton and transient, and also relies on container hierarchies to support others.

Outside of the realm of IoC container you can still see similar concepts on OSGi, EJB, COM+ and .Net Remoting. Take the last as a more reachable example, the WellKnownObjectMode enum reads Singleton, SingleCall, which is essentially the same Singleton/Transient pair supported by some IoC containers.

All is good, but then you face the challenges that this simple concept brings with it.

Incompatible Lifetimes

Not all lifetimes are compatible with each other. You won't have problems as long as it goes bottom up, from most restricted lifetimes depending on things served but more broad lifetimes. For instance, it's OK to have a per-web-request component that has a dependency on a per-session lifetime, which itself has dependencies on singletons. The opposite is not true, though.

Lifetimes that maps to non-boundaries context

Singletons can be mapped to the life of the container. You shutdown the container and all singletons are shutdown too. Per-session has a clearly boundary (session starts/ends) and so does per-web-request.

What about Transients? They can be map to the container lifetime too, but would that mean that we only shutdown them when the container is disposed? That would lead to growing memory consuption in some apps scenarios. What about per-thread? Do we get a notification we a thread is about to start and when it's about to die?

Ownership

This is not entirely related to lifetime, rather a common OOP problem. Usually you're forced to read the documentation to find out how you're suppose to deal with an object under a particular situation, as the API usually wont be able to tell you. Consider the following:

FileStream fs = ...

var processor = new FileProcessor(fs);
processor.Process();

FileStream clearly needs to be disposed. By externally creating it and passing to some other object, do you implicitly transfer the ownership? Some will say yes, some will say no. Others will go with "depends".

IMHO, for the sample above you do not transfer ownership, so the creator (you) have to dispose it. However if the FileProcessor itself created the FileStream, than it would have the ownership and the obligation to dispose it. Yes, I know, we have finalizers, but the way I see they are safeguards more than anything else. I'll come back to this.

Fixing our code:

using(FileStream fs = ...)
{
    var processor = new FileProcessor(fs);
    processor.Process();
}

The devil is in the details, though. What if FileProcessor is a long lived instance, that process the file in response to some external stimulus? In that case, the code above will early dipose a stream that the processor will need later.

Yeah, things are not as easy as they seem. You can come up with something that defines clear contracts, though:

 
var processor = new FileProcessor(new FileAccessor(new DirectoryInfo("./files")));

Depending on the FileAccessor API it would be more or less clear whose the ownership of file.

A stream is a relatively straingforward example as it's something that is clearly unshareable. Now consider an even worse situation:

var sender = new FtpSender();

var backupSvc = new BackupService(sender);
var docBrw = new DocumentUploaderService(sender);

FtpSender implements IDisposable, which closes the outgoing transfers and the main connection. Should the dependant services ever dispose them? Clearly no, as it's being shared. But how will the BackupService ever know it's shared? Same thing applies for DocumentUploaderService.

As someone who things conventions (and by consequence guidelines) tend to result in good things, I'd say that it would be safer to rely on a simple convetion: whoever created something has the obligation of destroying it. Obviously that will only apply to instances that have some sort of shutdown semantics like Stop, Close or Dispose.

Bringing all that to IoC containers. Windsor has always encouraged that. You don't care how things ended up on your constructor or properties, and you shouldn't care. In order words: <b>Thou shall shutdown them explicitly</b>.

Spring, however, deals with shutdown semantics for singleton, but leaves it up to you in the case of transients. I disagree with this as I find troublesome to have to know the lifetime of my dependencies and act accordingly - IMHO I shouldn't have to care - but I deeply understand their reasons. Here's why:

First, in order to shutdown short lived instances, you need to expose an operation to do that. Windsor and Ninject expose a Release method on the container interface. <i>What happens if the user doesn't call it? </i>

Secondly, imagine that you have instances that don't care for shutdown, but later on on the dependency chain there's a instance who cares. Guess what. You'll need to keep a chain of references in order to dispose that last one - what I like to call component burden (there is room for optimizations on the implementation algorithm, though). Why you need the chain? Because Release will be called on the first (root) instance.

So all in all, while it's easy to put an statement defining how ownership should be handled it does make things _way_ complex. There's a balance however, on what is the right behavior we should strive for, and what's a problem without a good solution that we shouldn't spend energy trying to fix as there is no fix good enough anyway.

What about the finalizer? Like I said, it's a good safe guard, but I rarely use it. You should be aware that instantiating an object that uses finalizer is more expensive. Also, in the call to finalizer I'm not supposed to reference other instances (ie dispose things other than wild unmanaged resource) as there is not invocation ordering guaranted. Maybe I'm spoilled by the fact that I've always relied on IoC container to do the proper shutdown for me. Implementing IStartable and IDisposable always meant that Windsor will call them, in the right time. Not having to rely on "what if" situations made my code simpler and allowed me to focus on other things. Boilerplate is for frameworks, my code should be about domain.

Now, I'm interested in hear from you basically two things:

- Do you often rely on shutdown semantics on your components?
- What do you fell MEF should support?

Introductions

hammett [MSFT] — Thu, 14 Aug 2008 09:07:00 GMT

If you don't know me my name is Hamilton Verissimo, and I recently joined the MEF team at MS (DevDiv). I'll use this blog to talk about MEF and - give me some time to settle in - other things I plan to be involved with.

My other blog will be kept but exclusively for Castle related stuff.