IoC Containers are Application Composers

I've been working with Jeremy D Miller's StructureMap IoC container lately. Over the weekend I also did some research on Castle Windsor, in order to properly offer an opinion to Krysztof Kozmic about whether he should remove nested containers from it. Previous to all this, the only IoC I'd really had the opportunity to use on a real project was Autofac. Maybe it's just the bias of first exposure, but I still like Autofac the best. But I can point to one big tangible reason that I like Autofac better, which the other two options don't have: lifetime scopes.

Lifetime scopes are the primary unit of context in Autofac. When the framework has to resolve a dependency, it doesn't pull it from a container. Rather, it pulls it from a lifetime scope. A lifetime scope is different from a container in that you can't change or query its configuration at runtime. It is a purely resolution-oriented interface. But more importantly, in concert with a few other features, it offers a very convenient way to establish what I call "resolution contexts" within your application.

A resolution context is a "bubble" within your application with some or all of its own resolution rules. You can dictate that within a given bubble, certain objects are guaranteed unique, and will be cleaned up when the context is disposed of. Or you can ensure that dependencies are resolvable inside the bubble, but not outside of it. By nesting bubbles that do this, you can enforce inter-layer dependency rules ensuring, for example, that the domain services layer does not depend on the UI layer. You can see the obvious reason that the word "scope" is used in the name: scoping is their explicit purpose.

The features that combine with lifetime scope to make it a truly powerful idiom are tags, and tagged registration. You can tag a lifetime scope with an object that identifies that scope. This value can also be specified in a given type registration to mark it as being unique within a scope having that tag.

Combined, these features allow you to tie instances of objects to a scope, and ensure that anything resolved within that scope gets a particular object. This can be particularly useful for managing things such as database transactions, or domain units of work. Or really any transaction-like operation consisting of a set of sub-operations involving resources which need only, or should only, exist for the duration of the parent operation.

Without this feature, it falls to the developer to explicitly write an object whose responsibility is to manage the lifetime or reach of these things, and another whose responsibility it is to generate and dispose of these scoping objects. This is essentially simple, but for an inexperienced dev it is a tough problem. For an experienced dev, it's annoyingly repetitive.

The thing I love about Autofac is that it supports tagged scopes which make it trivially easy to solve this problem. The thing I hate about Autofac is that you can't define as part of the registration process where you want these nested lifetime scopes to be generated. Instead, you must use a hook, a direct framework reference, a relationship type or some other extension mechanism, to dictate when nested lifetime scopes are introduced.

The reason I have these conflicting feelings is that Autofac approaches, but falls short of what I have come to consider the ideal role of an IoC container: to be the composer of the application. The use to which most of us put IoC containers today diverges from the implications of the name "container". While they do serve as containers in the sense that they hang onto shared (singleton) instances of objects, they also fill a factory role. And with Autofac's nested lifetime scopes, they can draw boundaries around self-contained operations and object graphs. Windsor prides itself on powerful, flexible "release" mechanisms, for cleaning up objects that are no longer needed. Again, this goes far beyond the role of a "container".

Yet despite this, the configuration API of most IoC frameworks still is highly container-oriented. We "register" types and interfaces, attaching bits of metadata here and there as needed. These are "stored" in the container, which can be queried or overridden at run-time by adding or removing registrations from the container.

But an IoC is at its most effective when it is acting not as a container, but as a rules engine, to regulate when new objects are created, and when existing ones are reused. Or how one object is chosen from many that implement a common interface. Or when and how object graphs are disposed of and resources cleaned up. These roles all build toward an overarching theme of "composing" the application. That is to say, building it up out of different blocks of functionality, fitting them together according to a pattern which is clearest when viewed as a whole.

This is why the ServiceLocator block from Microsoft makes me angry. While you can still configure the composition of your application using your IoC of choice, ServiceLocator exposes it as if it were a simple abstract-to-concrete mapping operation. And beyond that, the base idea of a centralized "service locator" completely undermines the goal of IoC in the first place, which is to invert the control. Don't ask for what you think you want. Just expose the dependency declaratively, and let it be provided to you as deemed appropriate by someone whose whole job is to know what you need.

I say we should embrace the composer idiom. I would love to see an IoC framework that took this role to heart, and wore it on its sleeve, so to speak, by expressing it naturally in its API. Autofac comes closest of any container I've used or researched, but it still shows some artifacts of its container heritage. One big improvement that could be made is a declarative configuration-time way of establishing when new scopes should be spun up. I posted a gist to this effect over the weekend and shared it with Krysztof Kozmic, hoping he'd take some inspiration from it for Windsor. But in truth, Windsor also still has a lot of other aspects that are tied to its identity as a "container".

Maybe it's time for someone to take another crack at the IoC problem. The ideal functionality is mostly all available out there. All that's lacking is an API that makes its true role obvious and natural.

Satisfying A Pair of Same-Typed Dependencies with Autofac

We'll take a break from the series on Windows services this week and cover some more Autofac / IoC / DI material. I hope to finish the services series with the final part next week.

Back in December I wrote a rather long post about the different Autofac relationship types. I covered what I considered to be the big ones, but there were a few that I didn't cover: IIndexed, and Keyed. I had an objection to these types that prevented me from examining them any further.

My Initial Objection

It's pretty simple. I don't want to have to reference the the IoC container framework in my classes. Accepted wisdom on IoC container usage is that you shouldn't reference the container, and I viewed this as an extension of that. Indeed I prefer to avoid referencing such infrastructure frameworks in core code wherever possible.

I feel the same way about the BCL's TypeConverterAttribute, and the XML serialization attributes, for example. It's an insidious form of coupling, and I really prefer to avoid having these little signposts sprinkled throughout the code of what framework I'm working with. Especially if they represent things that I can't sub out for testing, as is usually the case with the BCL.

In addition to the framework reference objection, I felt that this was just not a responsibility that belonged to the subject class. Using special parameter types or the like to denote such information was "cheating", akin to service location, and undermined the principle of Inversion of Control.

The purist in me had dug in on two separate fronts, and was ready for a fight. But recently I had an experience that taught me the value of these relationship types: I found I needed to inject two different implementations of the same service in the same place. I initially shied away from these relationship types. Instead, I decided I could solve the problem with a clever registration/configuration. After all, deciding who gets what implementations is what that's all about, though typically in a more generalized sense.

The Problem

My situation was that I had needed two different runtime instances of an image cache. One for full-size images, and one for thumbnails. And most commonly I needed to reference both of them in the same scope. If the two use cases existed in different contexts, I could possible use Autofac's nested container support to identify each one appropriately when needed. But in my scenario, I actually had a couple of classes that needed to make use of both caches. I gave the constructor for that class two parameters for injection, both having a datatype of the cache interface type. Then I went to work setting up the registration.

Without a major redesign, the solution has to involve attaching some metadata to each of two separate instances registered with the container. The container needs some way to differentiate between the instances. Since Autofac provides it, there's really no reason at all not to use the keying facility for registration. Given an interface ICache and an implementor Cache, the registration would look as below.


Now let's introduce another class that needs to use both of these caches.


Again, my instinct is to say that the class shouldn't have to say anything else. It's the container's job to figure out how to fill those dependencies. But what information does the ImageBrowser class expose that the container registration could use to determine which argument gets which instance of ICache? Well right now, there's not much there. Pretty much just the argument names. Can we use those to assign the ICache instances? Yes, but it ain't pretty.

OnPreparing¹

The way to access the parameter names for resolution is to hook the OnPreparing event, as seen here:


Our implementation of OnPreparingImageBrowser then looks like this:


This looks harmless enough, if a bit verbose. But is a problems. We have encoded parameter names in strings in our registration code. If we ever have to change those parameter names, or add more dependencies to the constructor, this registration code for ImageBrowser will be broken, but it will still compile. So unless you have some pretty magnificent tests for your IoC registration (which it seems is not easy to do), this is a regression bug waiting to happen. Furthermore, this code is very likely useless even if we have another class with these same dependencies. If the constructor arguments are named differently, we'll need another delegate for that set of constructor arguments.

So obviously argument names aren't the ideal way for the subject to communicate information about multiple dependencies of the same service type. And even using the argument names undermines my objection in spirit. It just does it implicitly, rather than explicitly. So let's just accept that we've already taken the first step and go the rest of the way. How can we communicate the necessary information in a sustainable way, that doesn't require us to go mucking around in the registration code if we shuffle things around a bit in ImageBrowser?

Three options spring to mind. One would be to use an attribute applied to the arguments of the constructor. But there's no native support for recognizing these in Autofac, so we'd have to write our own registration and resolution conventions. While it would be more resistant to change than the named parameter mechanism, it would require even more code on the registration side of things, to set up a convention-based registration that keys on the attributes. Not to mention having to define the attributes. This actually sounds like a fun exploration for another day. But today, we just want to get this working with a small amount of intuitive code.

Autofac has two mechanisms which we can use to reduce the amount of code we need here: IIndexed and Meta.

IIndexed<TKey, TComponent>²

Using Autofac's IIndexed mechanism is a simple change from where we are now. It involves a small change to the constructor of ImageBrowser, and removing code from the bootstrapper. That's right, a net reduction in code, without losing functionality. And there's nothing better than a good codectomy. So grab the scalpel and sculpt our new bootstrapper.


Note the removal of the OnPreparingImageBrowser method, and the reference to it in the ImageBrowser registration. That's the only change here. It's completely unnecessary code. The cache registries don't need to change because the IIndexed mechanism hooks right into the keyed registration just like our old strategy did.

The ImageBrowser constructor needs to change a bit to trigger resolution using the keyed registration. Here's the updated class:


The only change here is that we consolidated the separate cache arguments into one dictionary-style argument.

Meta<TComponent>³

Autofac's Meta mechanism works a little differently in that it allows you to attach data to a registration, and then to express a dependency on that metadata, in the subject class. The data takes the form of name/value pairs. If we wanted to use this, it would change our registration as follows:


We've replaced the call to Keyed with a call to WithMetadata. We also are essentially passing a name-value pair. There's also the option to attach an actual custom metadata object, and use the property names and values as the name/value pairs. Since we only need the one value, and it's not going to be changing at runtime, we can just directly assign the name and value easily.

Once again our constructor will need to change, of course. Here's the version that uses the metadata:


Here we're using the IEnumerable relationship type to get all the metadata objects, and then explicitly picking out the ones with the two with the values we're looking for. The CacheTypeChecker method is just a little comparison delegate generator that saves a bit of repeated code in the constructor.

The Lesser of Two Evils

Now this isn't necessarily the problem that Meta or IIndexed are meant to solve. It's really more meant for cases where the needed component is going to depend on runtime conditions. In that case, a simple service finder/locator is sometimes exactly what you want. There are often other ways to get the job done even then however, for example using lifetime contexts and contextual state objects to give the container all the information it needs.

In our case though, the dependency that's actually being injected bothers me a bit. It's sort of a limited service locator. The problem with that is that the specific dependencies aren't explicit. ImageBrowser is basically saying, "Er, I can't tell you exactly what I want, but if you give me everything like this, I'll pick out the ones I want". That is definitely not a pure inversion of control in this case, because we need exactly 2 instances of a very particular type.

We're basically limited to choosing the lesser of two evils. Do we couple to constructor argument names, or take a dependency on a service locator? I'm not sure I feel more strongly about either one. But the IIndexed option is definitely the least code, so that's the one I'll go with. And you can bet that if I run across a situation where the decision of which instance I need is made at runtime, I'll look to these solutions first.

Somewhere down the line I'll investigate that attribute convention option I mentioned in passing. I tend to dislike attributes, but if it's our code (rather than framework code) that does both the defining and the consuming... then maybe I can live with it.

---

GitHub Source Code References

1. Keyed registration with OnPreparing resolution
2. Keyed registration with IIndexed<TKey, TComponent> dependency
3. Metadata registration with Meta<TComponent> dependency

---

Taking IoC beyond DI with Autofac Part 2: Relationships

In my last post I began to discuss the applications of Autofac as a tool for accomplishing true Inversion of Control, beyond just simple Dependency Injection. Specifically, last time I focused on creation strategies and lifetime control.

This week I want to talk a little more about lifetime control, and a lot more about categories of dependency, also known as relationship types. Nicholas Blumhardt, the principal author of Autofac, has a great blog post on what he calls “the relationship zoo” which I think goes a long way toward covering this space. I was originally going to do something similar, but his post is far more authoritative, and I’m quite certain I couldn’t do better. So instead, I'll abstain from the explanation and code samples and stick to analysis and rumination. So go read his post, then please do come back here and I’ll expand on it with some of my own thoughts.

…

The reality is that I take issue with some of the dependency abstractions provided by Autofac. It can be quite dangerous to your design to rely on some of them without very good reason. Used properly and prudently, they can absolutely address some particularly painful problems, especially when the dependencies consist of code you don't own and can't change. But it’s also easy to let them creep in wherever they appear to be convenient, and severely corrupt your design and architecture by doing so.

Let me start with the warnings, and then I’ll move on to extoll some virtues that I think Nicholas neglected to identify.

The first relationship type to be wary of is Lazy<T>. The intended purpose, as Nicholas explains, is to avoid expensive operations or construction until or unless it’s necessary. The idea of a lazy object is an old one. It’s a pattern that has been around for a while. My opposition to the usage of this relationship type is primarily that the need for laziness is usually a function not of the usage by the dependent class, but rather of the implementation of the module that is depended upon. Where possible, the consumer should be ignorant of implementation details of its dependencies. Let’s recognize that expensive operations are rarely truly transparent or ignorable, but the fact remains that the responsibility for this situation lies with the module being depended on, not on the consumer.

I strongly believe that if the code of the module that will be resolved for this dependency is under your control, then it behooves you to wrap the laziness around this functionality elsewhere... either building it into the implementation, or wrapping it with some sort of facade. Where Lazy<T> comes in handy is when you don’t have control over this code, and the class poorly encapsulates its functionality such that it can’t sufficiently be wrapped in a facade. At that point the consumer cannot pretend to ignore the situation, and may benefit from delegating the responsibility for the laziness to the container.

I’ll attach my second warning to the Func<T> relationship. I’m wary of the plain Func<T> because it overlaps a great deal with both Lazy<T>. It shares the same issues as Lazy<T> while adding the sin of looking suspiciously like a service locator. Service locators can be dangerous because they subvert the goal of inverting control. A service locator hands control back to the consumer by saying, “just call when you need X”, rather than handing off the dependency and saying “I know you need X so here, use this for that”. This is very rarely the appropriate way of expressing the relationship. The exception would be in the case that the consumer knows for certain that it will require multiple instances of the service it depends on.

Let’s spin things back to the positive by looking at Func and the like. How does adding the extra generic arguments change this from a smell to proper IoC? It expresses a very particular type of dependency. Specifically, it says that this class depends on at least one instance of T, but which instance or instances are needed is a function of a few arguments which won’t be known until each instance is actually needed. This is useful if you have a service which must be constructed for each use and requires some primitive types to guide its behavior, such as an encryption object which requires a key at construction. Or if you have a few different implementations of the a service which are mapped to different run-time states, such as a set of logging mechanisms for different error severities.

The IEnumerable<T> relationship is similar to this last scenario in that it offers a way to say “I depend on all implementations of T, no matter what they are”. This is probably a rarer scenario. Usually a service will have one key implementation, or a couple with very specific and differing purposes which will be used separately in different places. The most likely way for an inclusive but generalized need like this to arise is in an add-on or plug-in scenario. And in that case, you’re likely going to need some up-front processing to get things loaded up before the implementations can be passed off as dependencies to other objects.

I should note that it is probably not all that unusual for IEnumerable arguments to show up in constructors. But more often than not, this will be in data classes which will be instantiated directly, or a single step removed via a factory method, rather than resolved by the container. These aren’t truly “services” and are very unlikely to be registered with the IoC container. The factory may be a service, but what it creates in this case is more of a data structure than anything. Data structures mean state, and usually highly contextual ones at that. Autofac more context-sensitive than many IoC containers, but even it has its limits. With data structures, usually the best solution is either a direct constructor call, or a light factory.

One more small step along the path is Meta<T, M>. This is relationship type that specifies a dependency not only on a service of type T, but on some piece of metadata of type M about the module that will be provided at runtime. This metadata may be used to decide whether or not to go through with making use of the service, or how to do it. In fact, metadata is a great way to handle the special considerations a consuming object may need to make for a lazy service implementation involving a long-running operation. Maybe 90% of the time, the app can simply halt for an operation, but for certain implementations of the service, it’s more prudent to display a friendly “please wait” message and a progress bar. Attaching metadata at registration is a great way to enable these types of decisions intelligently without hard-coding a universal expectation one way or the other.

The final relationship type to address is Owned<T>. This one can be quite handy. At first blush it seems like this might violate the same principles as Lazy<T>, but if you think about it, they are actually quite different. Owned<T> indicates that the object expects to be solely responsible for the fate of the dependency passed to it. This tells the programmer, “I’m going to use this up, and it won’t be any good when I’m done with it, so just clean it up afterward.” Believe it or not, this fits in perfectly with the recommended implementation pattern for the .NET IDisposable interface. That is, that at some point, some object takes ownership of the resources, and responsibility for calling IDisposable, absolving all other transient handlers of the same. Ownership is sort of the dual, or inverse, of a constructor dependency. The constructor dependency says “I know I’m going to need this object”, and the ownership claim says “when I’m done with it, it can be tossed out.” And Autofac happily obliges, releasing the dependencies when the consumer itself is released, calling IDisposable.Dispose as appropriate.

After a twitter conversation with Nicholas himself, it became obvious to me that Owned<T> is probably the better solution to my qualms about InstancePerLifetimeScope. By establishing that the consumer “owns” its dependencies, we have essentially established exactly the limited and definite lifetime context that I was asking for! Behind the scenes, a lifetime scope is spun up when the object is instantiated, with nested resolution rules being applied as a matter of course. And when the object is released, then so is the lifetime scope and anything that was resolved as a new instance in that scope. However, we do have a symmetrical limitation here. Both the creation and the destruction of the context are tied to this object. Once the context is created, it can’t and/or shouldn’t be shared with anything either above or adjacent to this object in the dependency graph, or the deterministic disposal Autofac prides itself on will subverted and become unreliable.

In these past two posts, I’ve covered the whole continuum of dependency creation, lifecycle, and relationship strategies that go beyond simple Dependency Injection to fill out the breadth of what Inversion of Control really means. And they’re all available via Autofac to be handled (for the most part) separate from the implementation of the consumer, and without writing boilerplate factory classes or resource management classes to make it work. I hope that in reading these posts some people may see that IoC is a broad space of patterns and solutions, and that IoC containers are powerful and useful and far beyond the naive use and even abuse that people put them to for simple DI.

Taking IoC beyond DI with Autofac Part 1: Lifecycle Control

People who have to listen to me talk about programming know that I’m a big proponent of Inversion of Control (IoC) containers and what they can do to clean up your code. Most people get introduced to IoC containers via Dependency Injection (DI). DI is another great way to clean up your code. It’s hard to argue against it, really. It decouples your code in a big way. Not only does this make it more testable, but because it aids in separating concerns/responsibilities, this also makes it easier for you to track down bugs when they do show up. But people rightly point out that you don’t need an IoC container to use DI and get these benefits.

I’m usually both happy and sad to hear that argument. On the positive side, it means that people are acknowledging the benefits of DI, which is great. The more people are using DI, the less god classes full of spaghetti code there are out there for me to unearth in future maintenance efforts. Another reason I’m happy to hear that argument is because it means that people aren’t confusing the means for the end. DI is a good thing, for the reasons I established above, not because, as some people seem to think, IoC containers are good and DI is what IoC containers do.

That last sentence there leads into the reason that I’m sad to hear people dismiss IoC containers as being unnecessary for DI. The problem is, DI isn’t the only benefit of IoC containers. DI isn’t what IoC containers do. IoC containers, as their name would indicate, invert control. They take a number of concerns that have traditionally been assigned to the class under consideration, and extract them out to the context in which that class is used. That context may be the immediate consumers of the class, or it may be coordinating code, infrastructure, data access, or any number of other locations in the application. But the point is that the responsibilities are removed from the class itself and given to other classes whose business it is to know what should be created, when, with what initialization, and how it should be disposed of.

A good IoC container does more than just wire up constructor dependencies. It goes beyond that and lives up to the breadth of this definition of IoC. And that is why I laud and evangelize the glories of IoC containers.

Lets take a look at one particular container that I’ve come to know and love: Autofac. It’s an amazing framework that offers an answer to nearly everything that the principles of IoC ask of it. Autofac has features for lifecycle control, object ownership, and deterministic disposal. It has features for nested scoping, contextual dependency resolution, and varied construction mechanisms. These are all concerns that are a function not of the consumer of a dependency, but of the cloud of code and functionality that surrounds it, of the nature and design of your application as a composition. And Autofac gives you ways to deal with them on those terms.

Autofac boasts strong support for robust lifecycle control. In the project wiki you’ll find it laid out under the topic “Deterministic Disposal”, but it’s about creation as much as it’s about disposal. When you register a module with an Autofac container, you have the opportunity to specify a scope strategy. This strategy will determine whether a new instance is created upon the request, or whether an existing one is pulled from the container. Furthermore, it will also determine when references to the instance or instances are released and Dispose called on IDisposables. I’ll be doing some explaining, but if you want to do your own reading on the available strategies, you can do so here: http://code.google.com/p/autofac/wiki/InstanceScope

The two simple lifetime scopes that everyone tends to be conceptually familiar with are found n Autofac’s SingleInstance and InstancePerDependency scopes. The former is roughly equivalent to the function of a singleton pattern implementation, while the latter corresponds to a factory pattern implementation. Autofac goes well beyond this, however, and gives you two more scoping strategies that let you manage creation and disposal of your components in a more nuanced and more powerful way.

Both of the two more nuanced scope strategies depend on Autofac’s support for “nested containers”. A nested container is essentially a scoping mechanism, similar to a method or class definition, or a using block. Nested containers are useful for establishing the architectural layer boundaries of your application. For example, in a desktop application you may have many windows coming in and out of existence, all operating on the same domain objects, persisting them via the same handful of repository classes. These windows may be created in nested container contexts that are spun up as needed, and disposed when the windows are closed. Some objects will be created new each time this happens, while others are unique and shared across the entire UI. The nested container is what allows Autofac to make the appropriate distinction.

Imagine you are writing a file diff’ing application. You have to show two documents at once in side-by-side windows. They are the same thing, in terms of functionality and data, and so could just be two different instances of the same object.... But they will share some dependencies, and have references to their very own copies of certain others.

Lets pick out a few pieces of this puzzle and tie them to Autofac’s features. You will probably have a file access service that allows you to operate on the files that you have loaded. There’s no reason to have more than a single copy of this in the entire app, so it can effectively be a singleton. The way you would express this to Autofac is via the registry.

Given the class and interface definition:

You would register the component as a singleton like this:

The run-time behavior you would see based on this registration is that only one instance of the FileAccess component will ever be produced by the container. Subsequent requests will just return the one that’s already constructed.

The next layer on top of that is the UI. You decide that you may want to be able to have multiple comparison windows open at once, without having to run separate instances of the app. But each of those windows is still essentially a full instance of your apps interface. They’re not exactly singletons, but they should be unique within their separate stacks. Whatever sub-context they are in, there should be only one.

Given the class and interface definition:

You would register the component using the InstancePerMatchingLifetimeScope strategy, like this:

One weakness of Autofac for this use case is that in order to establish the proper resolution contexts, you have to refer directly to the container. In this case it’s probably okay, since you can be fairly certain you’ll only ever need a Left context and a Right context. So you can probably create the lifetime scopes up front, store them away somewhere, and explicitly resolve these objects from the separate contexts when needed. A sample setup for this can be seen below.

Then you’d need to make sure that the LeftContainer and RightContainer were used explicitly to resolve the left and right ComparisonWindow components.

This works for us in this situation. But it’s not at all difficult to imagine a scenario, maybe even in this same app, where the contexts aren’t predetermined and static. For example, you may want have a worker thread pool, where each thread has its own resolution context. In fact this is a situation addressed explicitly in the Autofac wiki. Even there, it seems to be accepted that an explicit container reference in the thread pool is necessary. It doesn’t seem like there’s a great solution to this challenge at this time, though I will surely be keeping an eye out for one. This is messy, concern-leaking infrastructure code that I would really prefer not to have to write.

There’s another scoping type that’s related to this one. In fact it’s use is a bit simpler. This is the InstancePerLifetimeScope strategy. Note the subtle lack of the “Matching” adjective in the name. What this indicates is that the context is implied rather than explicit. The behavior specified by this strategy is that at most one instance will be created within the resolution context where the resolution happens, at whatever level of nesting that happens to be. Functionally, this differs from InstancePerMatchingLifetimeScope in that it doesn’t search the context stack for one particular context in which to do the resolution.

This strategy can be effective when you have a set architecture with a trivial tree structure. Well-defined layering is crucial. All the leaf nodes of your context tree need to be at the same depth in order to be certain when a new instance will be created and when not. For example, a website where you have a base layer for the whole web app, and a leaf layer nested within for each individual web requests. In our diffing app, if we can be certain that we need no more deeply nested containers beyond our LeftContainer and our RightContainer, and all significant service resolution will happen at those layers, then we may have a use for this strategy for the dependencies of our Left and Right windows and controllers

The registration for this strategy is very similar to the others. Given a class and interface definition such as this:

The registration would look like this:

The final scoping strategy is InstancePerDependency. As noted before, the behavior is roughly equivalent to an implementation of a factory pattern. Every resolution request for a service registered as InstancePerDependency will result in the creation of a new instance. In our diffing app, we may find use for this strategy with something like an alert dialog. There’s no need to keep an alert around when it’s not being shown, and in fact it should almost certainly *not* carry any state from one alert to the next.

So given a class and interface such as this:

The registration would look like this:

That covers most all of Autofac’s lifecycle control functionality. There are four strategies available: SingleInstance which approximates Singleton, InstancePerDependency which approximates Factory, and the more subtle and, honestly, difficult to use, InstancePerLifetimeScope and InstancePerMatchingLifetimeScope which are heavily contextual. I really wish that these last two were more manageable and directable. If they were, I think that Autofac could claim to easily address most any lifecycle control need with very little overhead and requiring few concessions to the framework. This would be a very noble goal. But as it is, their behavior will tend to be circumstantial rather than controlled and intentional. And the only hope of improving that situation lies in taking great pains to organize your design to account for the container’s shortcomings and then go on to break the rule of not referencing the container.

Despite these shortcomings, I believe there are many benefits to be found in relying on Autofac for lifecycle control where it’s possible and not overly problematic. Certainly I’ve saved myself some headaches in doing so. And we haven’t even begun to explore the dependency relationship patterns that Autofac supports out of the box. We'll dive into to those next time!