Put IoC front and centre
Bake inversion of control into the framework and reduce the reliance on inheritance. This will allow greater extensibility and enable new scenarios. A good example of this is MVCTurbine (http://turbineproject.com) - rather than developers having to roll infrastructure themselves, they could hit the ground running with their IoC container of choice.
Luke Bennett
shared this idea
11 comments
-
Peter Porfy
commented
Asbjørn: DI containers use System.Activator to create objects so it would be interesting if System.Activator would use a DI container to create objects.
I understand what you are saying but I don't think a DI container would be a great choice for core parts of the framework because you can't define a composition root on that level. It may use it as a universal factory (service locator) but I think that is harmful. Maybe some parts of the framework can be improved for easier dependency injection but a DI container is not relevant for this.
-
abatishchev commented
Microsoft.Practices.ServiceLocation.ServiceLocator was neved being updated, is bogus and badly designed (e.g. Current throwing an exception, this is terrible) thus it ultimately sucks and shouldn't be used by anybody until fix.
-
Asbjørn Ulsberg
commented
Peter, Mark; it's not hard at all. Microsoft just needs to provide a default container implementation that plugs into the existing Microsoft.Practices.ServiceLocation.ServiceLocator (which needs to be pulled into the core library) and then use the ServiceLocator to construct objects. Alternatively, System.Activator can be extended to support IoC containers.
This is not about making the core framework harder to use. The default instances of all objects should be like they are now, so if you don't want to use an IoC container, you shouldn't need to worry about its existence at all. But if you want to replace a core object with your own implementation, plugging it into an IoC container should be easy and supported by the framework. Today it's not easy, not supported by the framework, and implemented in several different ways via web.config (MembershipProvider, RoleProvider, etc), code registration (ControllerFactory), etc.
Doing this with IoC just provides consistency across the entire framework, eases testing and makes replacing core objects with custom implementations intuitive. Sure, there's security issues involved here, and I'm not saying absolutely all objects should be replaceable in all circumstances, but those that already are, should at least do it in a consistent way.
-
Peter Porfy
commented
How would you bake Inversion of Control into the framework? It makes no sense. Or you would like to see the framework to use a DI container for ad-hoc object creation? That would be a nightmare.
-
Mark Seemann
commented
What would that do? Where should it apply?
MVC and Web API already have 'good enough' extensibility points to allow you to hook in your DI Container of choice.
DependencyResolver (or whatever name it may go under) is a dead end. The framework needs less of such half-baked solutions, not more.
Web Forms doesn't have DI support, but I think it's better to just let it die than attempt to resurrect it with misunderstood 'DI support'.
-
Jonathan Allen
commented
Where is the down-vote button?
IoC should NEVER be front and center. It should be tucked away in a corner so that the bulk of the application doesn't even know you are using it.
-
Anonymous
commented
It does NOT need a MEF job.
-
Jeffrey Palermo
commented
This sounds good on its face, but I don't think IoC is the solution. The principles behind IoC are the solution. Composition over inheritence and fulfilling dependencies at runtime are two of the most important design principles.
-
malweka
commented
definitely needs a MEF job.
-
ssmith
commented
MEF
-
Michael L Perry
commented
This goes for WPF and Silverlight as well. App.xaml should not be one monolithic file, but a graph of dependencies.
