Nicholas Blumhardt : Autofac

Hosting MEF Extensions in an IoC Container

niblumha — Tue, 17 Mar 2009 01:14:32 GMT

There has been a lot of discussion among IoC container users about the similarities between MEF and IoC containers. Most of this has been addressing the question - “should MEF and an IoC container be used in the same app, or are they exclusive?”

One possible answer to this question is outlined below. It isn’t by any means the definitive answer, but if these are technologies you find interesting, hopefully this article will give you plenty of food for thought.

An IoC container is not required in order to use MEF. Unless you’re building or using an IoC container, this article probably won’t apply to you :).

Defining Extensibility Points

The Managed Extensibility Framework (MEF) in .NET 4.0 introduces a standard model for defining and consuming application extensibility points.

Central to this model is the ComposablePartCatalog type and its subclasses:

AssemblyCatalog and DirectoryCatalog can read set of attributes for defining extensions:

Here Export marks the Square class as an extension providing the IShape contract.

.NET 4.0 also introduces a class for assembling extensions into complete object graphs. This class is called CompositionContainer:

The role that CompositionContainer plays in a .NET 4.0 application is very similar to the role and IoC container might play in a .NET application today.

This has raised a lot of interest among IoC container users, who want to know how they can take advantage of MEF in their applications. Should CompositionContainer, for instance, replace their current IoC container, or can the two containers work together?

The answer to this question is trickier than it seems, because there are substantial problems associated with having more than one container in an IoC-driven application:

How do the containers mutually decide that an instance’s lifetime is over?
How is context maintained, so that the correct type gets its correct dependencies even when they’re provided by the other container?
If the graph building operation moves backwards and forwards between two containers, how can circular dependencies be detected (without StackOverflowException!)
How can diagnostic messages provide the ‘full picture’ when each container only knows about a portion of the graph being constructed?

(Some of this is a general problem with composing frameworks in general, and is felt today by IoC container users integrating with UI frameworks in particular. It might be called ‘competing for control’.)

The good news is that there is at least one way to get some benefits of MEF in an application that uses an IoC container without using two containers.

MEF/IoC Container Roles

Although similar in many respects, the goals of MEF and IoC containers are different, and this gives each technology unique strengths.

MEF is built for open systems – scenarios in which the complete set of components that make up an application is defined at execution-time.

This means that MEF:

supports self-describing components that carry all of the information required to use them
makes strong guarantees about how components will be loaded and manipulated, regardless of the execution environment
includes robust tools for finding and loading components in different media
allows components to be queried and inspected without necessarily loading or executing them

MEF is also part of the .NET Framework, so developers can learn how to use it once and then apply these skills in all MEF-enabled applications.

IoC containers, on the other hand, have focused on highly-decoupled yet primarily closed systems. I take the definition of ‘closed’ to mean that all application components are present during integration and testing.

This makes typical IoC containers:

highly customizable to suit the internal architecture of a specific application
extremely flexible in the criteria for what can be used as a component
easy to wrap around existing frameworks and legacy code

These requirements lead in different directions when designing composition technologies, but appear together in some applications.

Both MEF and typical IoC containers are flexible enough to fit to most scenarios; however, their ideal roles might be:

define third-party extension points using MEF
locate and load these extensions using MEF
structure and manage the host application’s fixed architecture using an IoC container

Hosting MEF Catalogs

There are several approaches to integrating MEF and IoC containers. The one described here is probably the most powerful/complete/complex, those interested in other perspectives might start with this recent article by Patrik Hägne.

Most IoC containers, and MEF, use a layered architecture:

MEF’s composition functionality is wrapped up in CompositionContainer, and its component model in ComposablePartDefinition and related types like ComposablePartCatalog.

Autofac, an open-source IoC container [disclaimer: written by the author] follows the same typical pattern, using different types: Container and IComponentRegistration. (Funq, Linfu, Ninject, Windsor, Spring.NET, StructureMap and Unity use similar abstractions.)

Autofac and MEF used in the same application, without any integration, look like:

The crossed-out arrow in the centre reflects the barrier that we’re trying to cross: the Autofac composition process won’t include components that are composed by MEF, and vice-versa.

This kind of cross-over is frequently desirable, e.g.:

Application components invoke extensions
Extensions need to access services provided by the host application

The diagram below shows how this issue can be addressed without introducing the ‘two container’ problem:

Rather than hosting the MEF components in a separate container, an adapter is used so that the MEF components are presented to the Autofac container as Autofac components.

The adapter allows MEF and Autofac components to participate in the composition process at the same time – each can have dependencies satisfied by the other.

The IoC container is chosen as the ‘host’ because:

The application components are the ones most likely to integrate deeply into the container, and since they’re IoC container components it makes sense that they are hosted in the IoC container
IoC containers don’t provide as robust a component mode as MEF does, so hosting components from any particular container in MEF is difficult

So how does this look in practice?

Example Application: IoC and MEF

You can download a very contrived example that demonstrates many of the moving parts here. This is not production quality design, so please don’t flame me for it :)

The example is a task scheduler – perhaps you can imagine it running as a Windows service. It has two extension points: the tasks that will be run, and an output device to which notification messages can be sent.

The extension points are regular MEF parts.

The tasks export an interface and specify the interval at which they should be invoked via metadata attributes:

Notification services are similar, exporting the IMessageNotifier interface:

The container is created and Autofac services registered as usual:

An extension method, RegisterCatalog(), allows a MEF DirectoryCatalog to be supplied to the container:

Note the list of services that will be imported from the catalog into the application. Parts can still export and import other contracts, but these won’t be available to Autofac components. This keeps the extensibility points of the application clearly defined.

Similarly, Autofac services have to be explicitly marked when they will be provided to MEF components:

There’s an example of an Autofac component consuming a mix of Autofac and MEF services:

As well as MEF components consuming Autofac services:

Everything feels natural, although there are a few awkward issues surrounding the consumption of MEF metadata in Autofac services. These should go away once the MEF Export type is a framework type (it won’t feel so leaky to inject exports into Autofac components.)

Limitations

MEF defines how individual components will be manipulated, not how they will be assembled into complete object graphs.

This makes sense for open systems, because regardless of how components are packaged, they should not make assumptions about their host environment beyond the contracts that their immediate dependencies supply.

When designing components that can be used in multiple applications, each component needs to be treated independently. MEF discourages thinking about catalogs of components as subsystems with a fixed configuration.

The biggest side-effect of these decisions is that while MEF components behave consistently whether hosted in MEF or another container, groups of components will probably behave differently.

MEF’s container also offers a different set of features from the typical IoC container – these may be sorely missed in highly-extensible applications, so if high extensibility is the goal the MEF container alone is likely a better choice.

Status

It will be some time before there is much empirical data on the benefits and pitfalls of this technique – YMMV, so be sure to carefully evaluate your needs before starting down this path. Experimental is probably the appropriate tag!

.NET 4.0 and MEF are not yet released, so these techniques may not even apply to the production version.

There is a whitepaper on the MEF site describing some of the technical requirements of the approach.

Some notes on the Autofac adapter are available on the Autofac wiki.

IoC on Silverlight

niblumha — Sun, 04 Jan 2009 20:48:33 GMT

A number of IoC containers have Silverlight versions - Ninject and Unity especially seem to have healthy Silverlight offerings. Silverlight 2.0 is a variant of the .NET runtime, so this isn't too surprising.

Thanks to Tyson Stolarski and Rinat Abdullin, Autofac recently joined their ranks with a Silverlight-compatible build. (This one is hot off the press, so test it thoroughly before you set out to build anything mission-critical :))

MEF hasn't released any concrete plans for Silverlight, but experimenters can probably coerce the Codeplex source into a compatible build by hacking the .csproj file.

If you're reading this blog and use IoC on Silverlight in one form or another:

What have your experiences been like?
Do you use IoC in the UI, the 'back-end' or both?
Does loose coupling/runtime composition get in the way of XAML-based designers?

I'd love to hear your thoughts!

Declarative Context Adapters

niblumha — Sun, 04 Jan 2009 19:59:42 GMT

The first post in this series introduced the problem of accessing IoC container features dynamically.

We brushed over two common patterns:

Global Container (or Static Service Locator)
Injected Context

Before we move on from this topic, I'd like to look at one more pattern in this theme that may not be in common use, but deserves some attention anyway.

This pattern I've labeled Declarative Context Adapter, and it builds on the strengths of Injected Context while moving from imperative implementation to declarative configuration.

Problem

After composition, a component requires dynamic access to features of the container that hosts it (the context.)

Commonly, this involves dynamically creating or locating instances from the container (e.g. see ControllerProvider in this article.)

Solution

Provide a domain-specific interface to the required functionality.
Describe how this interface should interact with the container using metadata or configuration.
A compliant implementation is supplied based on the metadata.

Example

One example of a Declarative Context Adapter is the generated factories feature of Autofac.

This feature uses .NET delegate types as the 'domain-specific interfaces'. The Shareholding.Factory delegate type below plays this role:

In this example, we want invocations of the Factory delegate to return instances of the Shareholding class created and wired up by the container. This example is a bit contrived, since usually there is some abstraction involved, but hey, it is just an example :)

The ContainerBuilder's method-chaining API allows the mapping between the delegate to the container's Resolve() method to be specified:

This is specified via the RegisterGeneratedFactory() method.

The only declarative configuration in this example apart from the delegate type itself, is the TypedService parameter that tells Autofac which service from the container should be returned whenever the delegate is invoked.

(Additional configuration options can describe parameter mappings for the delegate parameters, however these aren't available in the current release builds.)

Other components that need to instantiate Shareholdings can now have instances of Shareholding.Factory injected into them.

Discussion

To call this technique a 'pattern' is a bit premature, since the Autofac feature is the only implementation you can put your hands on.

The same functionality could be implemented on different containers, perhaps via AOP. It would also be preferable to support interfaces as well as delegate types.

While the examples have been related to instantiation or service lookup, context adapters could be defined for other container features like lifetime management or even component registration. Anywhere that Injected Context is used, it should be possible to generate a configuration-driven alternative.

Source Code

The tiny example from above can be downloaded here if you'd like to experiment with it.

Container-Managed Application Design, Prelude: Where does the Container Belong?

niblumha — Sat, 27 Dec 2008 03:32:00 GMT

There is surprisingly little information out there in cyberspace on how IoC containers should fit into application architectures.

In parallel with my MEF/Ruby series, I'm going to discuss some of the principles that I believe should be applied to "container-managed" application design.

The Enigmatic Ideal

In the world of systems built using dependency injection, you hear plenty of mysterious statements like:

“Except for when bootstrapping, don’t access the container directly!”

This kind of thing caused me to scratch my head for the best part of a year before I finally caught on to what was meant.

Basic Mental Models

When confronted with the task of designing an application around an IoC container, the place that the container sits in that architecture usually seems to be influenced by the designer's mental model of what, exactly, an IoC container is.

Model 1: a Dictionary of Services

The dictionary or associative array is one of the first constructs we learn about in software engineering. It is easy to see the analogy between a dictionary and an IoC container that composes objects using dependency injection:

Maps to:

All that appears to differ is:

Some fancy new terms ‘register’ and ‘resolve’ are used, instead of indexer access
The logger is created via reflection, saving some typing and configuration code in the case of inter-dependencies

If you come onto a project with established usage of a dependency injection container and had to figure out how to write the code you need to interact with the rest of the system, chances are this is the first mental model you’ll apply.

Model 2: an Abstract new() Operator

Dependency injection containers are often praised for eliminating implementation type dependencies. Going back to our example, we’ve made our request for an ILogger independent of the implementation type that provides it (ConsoleLogger in this case.)

Web frameworks like Monorail and ASP.NET MVC use our dependency injection container to create Controller instances in a similar way.

Perhaps it makes more sense to think of the container as an abstract new() operator?

Becomes:

Here our container usage has not only abstracted away the concrete type of our MailTransport but also taken care of configuring its Host property. (Configuration must be a feature of our abstract new() operator since the configuration parameters on an instance depend on its concrete type rather than the service it provides.)

Design Outcome: the Global Container

Following either of these mental models encourages you to think about the container as something you retrieve things from. Even the name 'container' pushes us in this direction.

From this perspective, there isn't much of a challenge in the application architecture design assignment!

We'll just create a static property Container on a class, say, Global and get instances from it using Global.Container.Resolve<MyService>().

Easy!

This snippet should be familiar as a pattern with another name: the static Service Locator.

Problems with the Global Container as a Service Locator

There are good reasons why this pattern can rightly be called an anti-pattern:

Fragility. The container acts like a bucket of global variables. All of the robustness that is achieved by forcing components to publicly declare dependencies is lost. Unexpected dependencies can appear between seemingly unrelated parts of an application, complicating maintenance.

Reduced Composability. When dependencies are injected, the container can be configured to provide different implementations to different consumers. This is often necessary when combining components that were built independently. When dependencies are retrieved from a global container, the container does not know the identity of the requestor, and is forced to return the same implementation every time.

Limited Reuse. Where the global container resides can limit the reusability of components that depend on it. Migrating components to a WPF application will require code changes if they depend on the global container attached to the HttpApplication class.

Implementation Issues. Concurrency, re-entrancy, circular reference detection, and component lifetime management are much harder/messier in a global container based solution.

Resumption of Control: Generally speaking, these issues arise because calling directly into a global container is a resumption of control. In a container-managed application, the container is given the responsibility of getting the right instances into the right places in order for work to be done. Calling into a global container takes over some of this responsibility in a much less manageable way.

Sometimes, because of the design decisions made in many current-generation frameworks, the Global Container is a necessity, but in order to advance the state of software engineering we need to look beyond this.

Thinking Inside the Box

The mental models listed earlier should have rung some alarm bells:

The container is a dictionary of services? Hang on! If I ask for the same service twice, why do I sometimes get different instances?

Good question. It is easy to configure a dependency injection container to return a new instance of the ConsoleLogger each time one is resolved. Not very dictionary-like, is it?

So the container is really an abstract new operator? Wait! If I sometimes get the same shared instance back, when can I Dispose() it?

These two models aren't even compatible. Sometimes the container hands out new instances, but sometimes what comes back from a call to resolve is a singleton, or an instance that will be shared within some kind of context like the current transaction.

So things are now confusing: who owns these instances, and where do they ‘live’?

Revised Mental Model: An Interconnected System of Objects

Here’s the problem: look at the example on the Autofac homepage. It shows how Register() and Resolve() are used in Autofac. This is a pretty common kind of introductory example to dependency injection. Notice what’s missing?

The most important classes in this example are not ContainerBuilder or Container. From an application architecture perspective, we need to see the Straight6TwinTurbo and Car classes!

The resolve operation is just a way of finding an entry point into a self-contained system.

The entire application resides within the container. There is no ‘outside’ except for whatever entry point gets the ball rolling. An understanding of IoC from this perspective does not revolve around its external APIs like Register() and Resolve().

Using this model, the container to gets component instances to the right place at the right time, and application design re-focuses on the implementation of the components themselves.

Design Outcome: Injected Context

This new perspective on the world leaves us with a challenge when implementing our revised IControllerProvider. This service needs to return (potentially) new, parameterised instances of the Controller type.

The solution, commonly implemented in applications today, is to allow the container to provide context to our controller provider:

We assume here that ControllerProvider is itself hosted within the container. IContext is an interface that Autofac automatically provides to any components that require it. You can create and use an equivalent interface in any other popular IoC container (there's a MEF example linked from below.)

IContext provides the instance resolution features of the container to the application, but in a controlled manner. The object implementing IContext provides the container's services, but may not be the container itself.

Because this pattern gives the container or application developer an opportunity to customise or proxy the IContext implementation handed out to any particular component, most of the problems associated with a Global Container are mitigated.

Container-Managed Application Design

If you feel like this article and its explanations are somewhat incomplete, you're right. As the title of this post suggests, it is an introduction to a series on the topic. I don't have all the answers, and I don't even have all the questions, so the installments may come in fits and starts. Nevertheless, if you're out to design robust architectures that make use of an component-based composition technology there should be something of interest for you.

I hope this article has whet your appetite!

Sample Code

The sample code, based on MEF preview 3, is very, very rough, and is really only worth consulting if you need to step through some running code in order to clarify the concepts in this article.