User1807617904 posted
David and Louis, thank you for responding.
As far as I can tell, there are several forces at play, but it may be sensible to divide them into two categories - at least, this is how it currently sounds to me:
- Better DI options for framework users (i.e. programmers using the various ASP.NET frameworks to build web sites/services)
- Better integration of the various ASP.NET sub-frameworks (MVC, Web API, Web Forms, etc.)
The first goal, it seems to me, is aimed at Microsoft's customers; the second, at Microsoft's developers. In my experience, when you have two different concerns, it would be wise to keep them separate. From what you are writing, it sounds to me like these
two concerns are currently being conflated, and I must admit that this makes me uneasy.
Both of you paint with rather broad strokes, so it's difficult for me to see exactly how your proposed design address the problems you list. Can you perhaps share some more details on how the particular design helps to address a particular problem? Out of
self-interest, I really would like to help, because in my experience, once you start modeling things around the Service Locator anti-pattern, there's always a better, cleaner, simpler alternative available. Sometimes, it takes experience
to identify those alternatives, and that's why I'm offering my help: more brains are better at finding a good solution than fewer brains :)
Here's an example of a question I got the other day: what about a project with both Web.Api and MVC controllers? Where is the composition root to handle both?
That's easy to do. You just create a Composition Root that implements both required interfaces:
public class SomeCompositionRoot : IHtppControllerActivator, IControllerFactory
{
// Singleton-scoped services are declared here...
private readonly SomeThreadSafeService singleton;
public SomeCompositionRoot()
{
// ... and (Singleton-scoped services) are initialised here.
this.singleton = new SomeThreadSafeService();
}
// Implement IControllerFactory here to support MVC
// Implement IHtppControllerActivator here to support Web API
}
In this way, any services a (programmer) user of ASP.NET needs to share between MVC and Web API can simply be declared as a class field of the SomeCompositionRoot class. Then you create a single instance of the SomeCompositionRoot class, and register it
with both MVC and Web API.
From the viewpoint of a user of the ASP.NET frameworks, nothing more is required to flow services between frameworks. The necessary extensibility points are already in place.
From your answers, I understand that you Microsoft programmers also feel a need to be able to share services, code bases etc. across various sub-frameworks, and that sounds perfectly sensible, but is there any reason you can't just use Pure DI? Why do you
need to introduce a Container Abstraction?
Dependency Injection is a set of principles (mainly the
Dependency Inversion Principle) and patterns, and is best applied without using a DI Container.
Is there any particular reason you decided that something like this
public interface IServiceLocator
{
T Create<T>(object context);
}
is better than something like this?
public interface IFactory<T>
{
T Create(object context);
}
Can you share one or more concrete examples of how an Abstract Registration API solves a particular problem? Again, I would be very interested in seeing this, because (out of self-interest), I would like to propose a better alternative if I can identify
one.
