The Injected Context

Nicholas Blumhardt (MEF/Autofac) has started a series of posts on Container-Managed Application Design where he talks about how IoC containers should fit into an application architecture. I like the delivery of the post in how it focuses on the ‘Mental Models’ most of us have formed about how an IoC container should work, and the design outcome which corresponds to our way of thinking.

Nicholas points out some of the issues with a traditional approach of a static global container (Fragility, Reduced Composability, Limited Reuse and Resumption of Control). These are issues which I have seen peers solve repeatedly as of late by delegating resolution though a provider/proxy interface like IResolver<T> or Resolvable<T>.

By adding a layer of indirection between the container and component, ala Injected Context, the component can customize a parameterized buildup, manage its own object lifetime, configuration, and disposing of its resources. This allows us to build modules which are ‘more’ composable, extensible, decoupled, <insert buzz word>, etc. I am not sure I fully grok all the benefits yet, but I am looking forward to reading more.

On the same note, when I was I Kaizenconf earlier this year, I attended a workshop on MEF with Glenn Block. During the session we talked about how MEF could use Export Providers to create child containers to solve many of the aforementioned problems, as well as a few others ( like a corrupted container taking out the whole app). So imagine a simple scenario if you will, an IoC parent container which has a child container responsible for building up a graph of say… an Asp.net page or MVC controller, then disposing the child container/context and all of its object instances once the handler has finished processing the request. Cool 🙂