Imagine every one of your controllers requires 5 dependencies:
So now - instead of having to remember to create a constructor with the 5 dependencies every time, you would create a base class that already has those dependencies fulfilled using property injection.
Every controller that inherits from the base class therefore would have the 5 dependencies fulfilled by default. Users need not remember to have a giant list of dependencies injected at the constructor of their controller, let alone calling base() and passing some of these constructor parameters to the base class. That would defy the point of the base class if you have to wire everything yourself and remember to use the said base class by calling its constructor.
The point being is that the devs should only focus only on things that pertain to their use case because the 5 other common dependencies would already be resolved.
PS. You killed every other DI framework. Why?
If you want property injection, you should switch to another container, like Autofac or StructureMap...
Are you going to pay the bill migrating from Web API 2 to Core? No? Well you should.
Just because you guys grew a consciousness and decided this was a bad practice - It's going to cost hundreds of thousands of dollars for businesses to refactor code that depended on base class controllers that use property injection.
To you - it doesn't matter; YOU ARE CONTENT WITH BEING RIGHTEOUS because YOU DO NOT PAY THE DEVELOPMENT COST OUT OF POCKET. It's no big deal for a small, "mom and pop" shops either. But think enterprise. Think of micro-service architecture written in MVC or WebAPI 2 with a deployment of 20, 30, 50 micro-services. Migrating to the now "stable" core 2 is a tremendous initiative, thanks to opinionated wise guys like you who decided it's OK to drop a feature out of the blue.
You have no business in making architectural changes with such deep impact to the developer community, let alone to provide a "matter of fact opinion" in such manner. Either provide an upgrade path, or fully working samples using Autofac/Structure map using ASP.NET Core 2.
thanks to opinionated wise guys like you who decided it's OK to drop a feature out of the blue.
What are you talking about? I think you need to read up on some documentation. Web API or MVC has never supported property injection out of the box. Neither does ASP.NET Core. You've always had to plug in a third party container, this is the exact same scenario today.
Either provide an upgrade path, or fully working samples using Autofac/Structure map using ASP.NET Core 2.
I don't think it's Microsoft's responsibility to document how you use all existing containers in the ecosystem with their stack. If you want to check out how you can integrate StructureMap or Autofac, you should see their respective documentation, like here or here.
Migrating to the now "stable" core 2 is a tremendous initiative
ASP.NET Core is a totally different product and not really meant for migrating from Web API or MVC. There's the Microsoft.AspNetCore.Mvc.WebApiCompatShim package, but that's only to slightly ease a transition for some people. Both Web API and MVC will be supported and patched for many years to come, there's no need to migrate unless you really want to.
You have no business in making architectural changes with such deep impact to the developer community, let alone to provide a "matter of fact opinion" in such manner.
I'm not really sure what "architectural changes" you're referring to, but anyway, for a totally new and different product, I think Microsoft can do whatever they see fit. And a lot of the changes have received a lot of praise from all around the .NET community.
Also, BTW, I do not represent Microsoft. I'm merely a .NET open source citizen, trying to help out people asking questions on GitHub without reading documentation first :wink:
This issue is being closed because it has not been updated in 3 months.
We apologize if this causes any inconvenience. We ask that if you are still encountering this issue, please log a new issue with updated information and we will investigate.
Most helpful comment
What are you talking about? I think you need to read up on some documentation. Web API or MVC has never supported property injection out of the box. Neither does ASP.NET Core. You've always had to plug in a third party container, this is the exact same scenario today.
I don't think it's Microsoft's responsibility to document how you use all existing containers in the ecosystem with their stack. If you want to check out how you can integrate StructureMap or Autofac, you should see their respective documentation, like here or here.
ASP.NET Core is a totally different product and not really meant for migrating from Web API or MVC. There's the
Microsoft.AspNetCore.Mvc.WebApiCompatShimpackage, but that's only to slightly ease a transition for some people. Both Web API and MVC will be supported and patched for many years to come, there's no need to migrate unless you really want to.I'm not really sure what "architectural changes" you're referring to, but anyway, for a totally new and different product, I think Microsoft can do whatever they see fit. And a lot of the changes have received a lot of praise from all around the .NET community.
Also, BTW, I do not represent Microsoft. I'm merely a .NET open source citizen, trying to help out people asking questions on GitHub without reading documentation first :wink: