I suggest you ...

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.

1,278 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    I agree to the terms of service
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Luke BennettLuke Bennett shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

    21 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      I agree to the terms of service
      Signed in as (Sign out)
      Submitting...
      • Daniel RothAdminDaniel Roth (Admin, ASP.NET Future Feature Feedback) commented  ·   ·  Flag as inappropriate

        We are addressing this feature request in ASP.NET vNext (http://www.asp.net/vnext), which introduces a central abstraction for dependency injection. Out of the box we provide a simple IoC container to bootstrap the system, but you can easily replace it with your IoC container of choice. You can follow our progress on ASP.NET vNext at http://github.com/aspnet.

      • Scott McFaddenScott McFadden commented  ·   ·  Flag as inappropriate

        @Daniel Roth, Please consider adding IOC support for custom IHttpModule instances. Registering HttpModules via web.config is very limiting.

        DynamicModuleHelper.DynamicModuleUtility.RegisterModule is a good first start but it is limited to module types and can not inject module instances. Even better would be if the user could specify a custom module factory for creating IHttpModule instances (similar to how MVC does it).

        We have to jump through some serious back door / unsupported / brittle hoops to make http module constructor injection work in current ASP.NET 4.51.

      • Asbjørn UlsbergAsbjørn Ulsberg commented  ·   ·  Flag as inappropriate

        Andy writes: "Adding solutions to a core framework because they are seen elsewhere usually tends to end up with the framework being quite messy over time."

        That's exactly where we are today. The .NET framework is already messy. There's a plethora of ways to extend it. You can do Provider-like stuff with XML configuration, some places there's Provider-stuff you can do with code, but sometimes the code adding the providers need to run at a certain time in the bootstrap of the application so you have to add it through the PreApplicationStartAttribute, then you have the ServiceLocator-based in ASP.NET MVC and Web API. These are just some, from the top of my head.

        Why can't all of these different IoC techniques be obsoleted in favor of one, central, common IoC container that doesn't need to be "front and centre", but that is used (transparently, if you don't want to bother with it) in every part of the .NET framework? Why are all these different ways of extending and replacing parts of the .NET framework required to be different?

      • AndyAndy commented  ·   ·  Flag as inappropriate

        Not sure I agree with this request. IoC is really an application architecture technique and can be achieved in a number of different ways. For example, in .Net framework 4 and higher there is MEF and MAF which work together to provide some of this functionality. A good developer can also implement their own version of IoC tailored more specifically for their application.

        Adding solutions to a core framework because they are seen elsewhere usually tends to end up with the framework being quite messy over time. My preference is to just have a core of basic functionality that can be layered up or extended to provide the required functionality by the developer. It is only a 10 minute job to do this type of design using any visual design tools or even using the old traditional and reliable pencil and paper method.

      • Asbjørn UlsbergAsbjørn Ulsberg commented  ·   ·  Flag as inappropriate

        It's incredible that so many people are unable to grasp the fact that IoC can be made even more invisible in the framework than the current chaotic Provider/Factory/Configuration "system". IoC is just a well defined way to extend the framework, which takes preference to using interfaces as a way to define contracts between interdependent parts.

        Using IoC doesn't mean that everyone needs to find, learn and install an IoC container in every solution. It doesn't mean all components they want to use needs to be registered in the container. It doesn't mean that all the code they write needs to adhere to an IoC pattern. It just means that if people want to, it's possible.

        Right now, it is absolutely impossible to do anything sensible with most parts of the .NET framework. There are just too many static classes that do "magical" stuff, bootstrapping the whole AppDomain without you being in control at all. The only way to extend anything is to inherit massive and bloated abstract base classes which gives you more than you want and doesn't allow you to override the functionality you do want.

        Using IoC is more about having the .NET framework follow good coding practices and less about choosing an IoC container. It's about having one, clear way to extend and replace components of the framework, instead of the myriad of different ways we have today.

      • Anonymous commented  ·   ·  Flag as inappropriate

        Many solutions do not fit the IoC pattern. Avoid putting this in the framework or as a preferred solution type.

      • Jonathan McPhailJonathan McPhail commented  ·   ·  Flag as inappropriate

        I agree with Seemann, this is already so incredibly easy to do, it offers little to no benefit and will only confuse new users that aren't familiar with ioc. Furthermore, how this is done could impose unwanted restrictions on certain other IOC frameworks that don't come "baked in."

      • Peter PorfyPeter Porfy commented  ·   ·  Flag as inappropriate

        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.

      • abatishchevabatishchev commented  ·   ·  Flag as inappropriate

        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 UlsbergAsbjørn Ulsberg commented  ·   ·  Flag as inappropriate

        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 PorfyPeter Porfy commented  ·   ·  Flag as inappropriate

        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 SeemannMark Seemann commented  ·   ·  Flag as inappropriate

        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 AllenJonathan Allen commented  ·   ·  Flag as inappropriate

        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.

      • Jeffrey PalermoJeffrey Palermo commented  ·   ·  Flag as inappropriate

        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.

      ← Previous 1

      Feedback and Knowledge Base