MEF and more

MEF and ASP.NET MVC sample updated

hammett — 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 — 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 — 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 — 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.