Jun 25, 2014 02:18 AM|ploeh|LINK
Mystere, reading your comment, I get the impression that you seem to think that DI requires a DI Container. My entire feedback is that if you model 'DI support' with implicit assumption that a DI Container is a required component of doing DI, you'll
arrive at a horrible mess.
Dependency Injection is a set of principles (the
Dependency Inversion Principle) and patterns (Constructor Injection,
Abstract Factory, etc.). It's
best done without a DI Container, but you can add a DI Container to the mix
if you have special requirements.
A pervasive DI model is a model that follows these principles and patterns; it's not a model that attempts to force a
Conforming Container into the code base.
"One of the big problems with DI right now is there isn't an easy (or good) way to develop a third party library that uses DI"
What makes you think that? It's perfectly possible to write a
DI friendly library for ASP.NET. One example is
Hyprlinkr: the entire code base of Hyprlinkr is based on the DI principle and patterns, and there's absolutely no DI Container involved in the Hyprlinkr code base. Yet, if you wish to wire Hyprlinkr up with a DI Container, you can easily do that. The reason
is that, instead of attempting to force a Conforming Container upon you, the library is simply DI friendly.
"All too many people look at DI as an application domain problem, but it's not. It's a system domain problem"
It's both; it's just the proper way to do object-oriented design.
"Are you going to make us override 200 different extension points"
Hardly. You listed Controllers, Filters, Value Providers... That would be three different extensibility points for a framework. The rest of the services you mention are just that: Services. You can compose these from within your Controllers,
Filters, etc. if you need to. In reality, there's probably going to be more then three extensibility points for a framework, but hardly 200; it's going to be a (small),
finite number of well-known extensibility points.
"The fact is, I don't *WANT* to write custom factories."
And you don't have to, either. If you want to use the DI Container of your choice, you can. Here's a
completely reusable implementation of ASP.NET MVC's IControllerFactory, using Castle Windsor:
public class WindsorControllerFactory : DefaultControllerFactory
private readonly WindsorContainer container;
public WindsorControllerFactory(WindsorContainer container)
this.container = container;
protected override IController GetControllerInstance(
RequestContext requestContext, Type controllerType)
public override void ReleaseController(IController controller)
You can create similar implementation for the other, well-known extensibility point of the framework, but you don't even have to do this yourself. Your DI Container vendor can do this as a pre-packaged Glue Library and publish it on NuGet,
because these implementations are universally reusable.
My point is that a Conforming Container isn't required here; in fact, it's completely redundant, so only amounts to overdesign and needless complexity.
So, I don't believe that I'm "missing a lot of important points". Quite the contrary, I'm just pointing out that there are
much simpler solutions available to address all of these concerns, rather than the currently proposed architecture.