4 ms·

This is part of a larger push to make ASP.NET Core and .NET easier for beginners. The difference between node.js + express vs. ASP.NET Core was a lot of boilerp

by oaiey 5y ago

This is part of a larger push to make ASP.NET Core and .NET easier for beginners. The difference between node.js + express vs. ASP.NET Core was a lot of boilerplate to return the first Hello World. Overcoming that churn is a huge problem for .NET adoption. Do not take three-line-minimal APIs as the end product for robust, safe and reliable endpoints. We all know better than trusting 3-line-presentations. As a seasoned .NET programmers I have a love-hate relationship to this new set of features (there are more!!!). The simplicity for rapid prototyping (or beginners) vs. the organized OOP template. The .NET 6 release will be very controversal. .NET will not get worse, however, a lot of (existing .NET/Java) people will complain about the new project/coding style attached to it.

Hawxy 5y ago
I've recently started using the new .NET 6 templates and honestly I don't miss the OOP boilerplate. Yes it's a bit of a shock at first, but you quickly realize that having your ASP.NET Core startup code split into two files and three functions has no real-world benefit. I'll still be using traditional controllers for my endpoints, however the syntactic sugar in C# 10 does improve the experience by reducing nesting and noise in general (file-scoped namespaces & implicit global usings). Overall I'm pretty happy with it.
- jayd16 5y ago
  >code split into two files and three functions You could always put multiple classes in a file if you wanted to organize that way. The new language changes just reduce nesting and boilerplate the IDE already took care of. (which isn't nothing). These framework changes to focus on lambdas is pretty nice though.
kumarvvr 5y ago
When it is purely about ASP.NET, getting rid of the old style Startup class is ok for me. The code is more compact, concise and less verbose. Most of the code in the startup is not touched in any meaningful sense after the initial setup.
corpdronejuly 5y ago
The bigger issue for me will be the way that these kinds of things tend to split communities. It doesn't do big enterprise devs much good if we have a lot of cool new features if there's no path towards using them in our 20 year old legacy applications that keep the business running.
- giobox 5y ago
  If you are a server side web app, the migration process from legacy net Framework app to net 5/6 has gotten _a lot_ easier in past few years. The biggest barrier for most in my experience has been getting through the project file (*.csproj) changes needed. Even today, there is still no fully automated way to do it. Thankfully, after ~4 years of community complaints, Microsoft finally aquiessed and made a CLI tool that does about 80 percent of that work: https://github.com/dotnet/upgrade-assistant https://github.com/dotnet/upgrade-assistant Before the release of this tool, you had to rely on community made tools/guides or just rewrite the project file by hand to the new format. I inherited a project with over 600 large net4x csproj files - prior to this tool Microsoft's official stance was "rewrite them by hand". This goes down like a cup of cold sick at many Enterprise software shops with hundreds or thousands of project files to update. I still think the upgrade process needs some more polish/wizards in the VS UI, for junior developers especially, but it's gotten much better. The vast majority of important third party dependencies are all net5 ready now in my experience now, so often just replacing the csproj file and setting target framework to net5 is enough. If you have a legacy WinForms/GUI app however and want full cross-platform benefits of net5... cost to move to modern UI framework can be significant. CLI apps/web apps are by far the easiest to port to net5.
  - coldacid 5y ago
    I don't think moving from legacy .NET Framework to modern .NET is the issue here. I have a web API application that has moved from .NET Framework 4.5 to .NET Core to .NET 5 and just updating for the newer framework has been the simplest part of each upgrade. The real problems come with the changes to the ASP.NET libraries and the changed expectations regarding how such applications are built. This push towards the "minimal APIs" for .NET 6 may be great for trivial or just-bigger-than-trivial projects but it starts falling apart whenever you have something more complex. The setup class system of older ASP.NET editions, while decried as boilerplate, actually makes it easier to manage the configuration and structure of larger web app projects. I don't expect to ever move any of the ASP.NET projects that I work on to use these minimal APIs, and I expect that any new projects will be quickly adapted away from them out of the new project templates out of Microsoft.
mathw 5y ago
I'm happy to get rid of the "organized OOP template" which is really just a bloaty mess of unnecessary classes. Given that all the IoC and request binding systems are supported in these minimal APIs I have no reason to believe I'll ever have to write a Controller class in .NET 6 again at the moment. And I won't miss it. The MVC pattern from ASP.NET MVC never did make sense for web requests.
- oaiey 5y ago
  I never considered this as OOP ... they are just names to give some organization. I think the only OOP is the instantiation of the controllers ... which are instantiated per request => pointless ;). So you are right, easy to transfer, but we will see midterm new file/naming based structures showing up when the first teams working with minimal apis with massive amount of apis.
  - merb 5y ago
    > I think the only OOP is the instantiation of the controllers ... which are instantiated per request => pointless ;). which has nothing to do with oop. that is IoC and they are (by default) scoped per request (but do not need to be scoped per request, singleton controllers are fine. (AddControllersAsServices)) btw. controllers by default do not get "built" by IoC but the helper "ActivatorUtilities#CreateInstance<T>(IServiceProvider, Object[])" uses it to resolve dependencies of the controller. if you add "AddControllersAsServices" it will use the IoC directly and skip using "ActivatorUtilities#CreateInstance" (and the IServiceProvider of the controller as created with the IServiceScopeFactory) and you can basically overwrite the behavior however you want, by using `IControllerFactory`.

by oaiey 5y ago

Hawxy 5y ago

I've recently started using the new .NET 6 templates and honestly I don't miss the OOP boilerplate. Yes it's a bit of a shock at first, but you quickly realize that having your ASP.NET Core startup code split into two files and three functions has no real-world benefit. I'll still be using traditional controllers for my endpoints, however the syntactic sugar in C# 10 does improve the experience by reducing nesting and noise in general (file-scoped namespaces & implicit global usings). Overall I'm pretty happy with it.

jayd16 5y ago
>code split into two files and three functions You could always put multiple classes in a file if you wanted to organize that way. The new language changes just reduce nesting and boilerplate the IDE already took care of. (which isn't nothing). These framework changes to focus on lambdas is pretty nice though.

kumarvvr 5y ago

When it is purely about ASP.NET, getting rid of the old style Startup class is ok for me. The code is more compact, concise and less verbose. Most of the code in the startup is not touched in any meaningful sense after the initial setup.

corpdronejuly 5y ago

The bigger issue for me will be the way that these kinds of things tend to split communities. It doesn't do big enterprise devs much good if we have a lot of cool new features if there's no path towards using them in our 20 year old legacy applications that keep the business running.

giobox 5y ago
If you are a server side web app, the migration process from legacy net Framework app to net 5/6 has gotten _a lot_ easier in past few years. The biggest barrier for most in my experience has been getting through the project file (*.csproj) changes needed. Even today, there is still no fully automated way to do it. Thankfully, after ~4 years of community complaints, Microsoft finally aquiessed and made a CLI tool that does about 80 percent of that work: https://github.com/dotnet/upgrade-assistant https://github.com/dotnet/upgrade-assistant Before the release of this tool, you had to rely on community made tools/guides or just rewrite the project file by hand to the new format. I inherited a project with over 600 large net4x csproj files - prior to this tool Microsoft's official stance was "rewrite them by hand". This goes down like a cup of cold sick at many Enterprise software shops with hundreds or thousands of project files to update. I still think the upgrade process needs some more polish/wizards in the VS UI, for junior developers especially, but it's gotten much better. The vast majority of important third party dependencies are all net5 ready now in my experience now, so often just replacing the csproj file and setting target framework to net5 is enough. If you have a legacy WinForms/GUI app however and want full cross-platform benefits of net5... cost to move to modern UI framework can be significant. CLI apps/web apps are by far the easiest to port to net5.
- coldacid 5y ago
  I don't think moving from legacy .NET Framework to modern .NET is the issue here. I have a web API application that has moved from .NET Framework 4.5 to .NET Core to .NET 5 and just updating for the newer framework has been the simplest part of each upgrade. The real problems come with the changes to the ASP.NET libraries and the changed expectations regarding how such applications are built. This push towards the "minimal APIs" for .NET 6 may be great for trivial or just-bigger-than-trivial projects but it starts falling apart whenever you have something more complex. The setup class system of older ASP.NET editions, while decried as boilerplate, actually makes it easier to manage the configuration and structure of larger web app projects. I don't expect to ever move any of the ASP.NET projects that I work on to use these minimal APIs, and I expect that any new projects will be quickly adapted away from them out of the new project templates out of Microsoft.

mathw 5y ago

I'm happy to get rid of the "organized OOP template" which is really just a bloaty mess of unnecessary classes. Given that all the IoC and request binding systems are supported in these minimal APIs I have no reason to believe I'll ever have to write a Controller class in .NET 6 again at the moment. And I won't miss it. The MVC pattern from ASP.NET MVC never did make sense for web requests.

oaiey 5y ago
I never considered this as OOP ... they are just names to give some organization. I think the only OOP is the instantiation of the controllers ... which are instantiated per request => pointless ;). So you are right, easy to transfer, but we will see midterm new file/naming based structures showing up when the first teams working with minimal apis with massive amount of apis.
- merb 5y ago
  > I think the only OOP is the instantiation of the controllers ... which are instantiated per request => pointless ;). which has nothing to do with oop. that is IoC and they are (by default) scoped per request (but do not need to be scoped per request, singleton controllers are fine. (AddControllersAsServices)) btw. controllers by default do not get "built" by IoC but the helper "ActivatorUtilities#CreateInstance<T>(IServiceProvider, Object[])" uses it to resolve dependencies of the controller. if you add "AddControllersAsServices" it will use the IoC directly and skip using "ActivatorUtilities#CreateInstance" (and the IServiceProvider of the controller as created with the IServiceScopeFactory) and you can basically overwrite the behavior however you want, by using `IControllerFactory`.