The old convention based model for controllers, was really difficult to understand and debug. You never knew what routes exactly were discovered by reflection. It was just too much magic, and too many conventions.
I hope this will make it easier. Reminds me of the good old Nancy times.
More importantly, if the default is to depend heavily on conventions, MS should have had a big glaring button / warning / notification in the Introduction page, which summarizes all the conventions used. Would have saved many beginners a lot of time.
I am an experienced programmer and was very frustrated having to search for all the conventions used in the framework.
Absolutely. I've wasted hours doing things that, if I'd been shown the way Microsoft wanted me to do them, I'd solve in 10 minutes, but instead I need to spend a ton of time trying to figure out why the new variable on my model isn't binding correctly because I didn't realize they need to be properties.
That always drove me nuts. You need to learn all those conventions from the examples. And then you always got the strangest surprises and still needed to use attribute based routing.
Something that drives me crazy about the current ASP.NET Core documentation is that it is overly example based. I wish there were more comprehensive coverage of the subsystems.
True story. We developers are an interesting species. Documentation is for us never sufficient because we want to know how the sausage is done down to the if statement.
1) Startup time: reflection can take a ton of time to run. It only needs to happen once, but especially as more and more web servers move to idle models where cold startup time matter rather than just holding on to a warm service, it's not always as amortized as before.
2) AOT compilation support/size: relying on Reflection APIs means that much more metadata/symbol data has to be preserved during an AOT compilation. This impacts metadata that needs to be passed to the AOT pass and final build size from the AOT. Some web applications are interested in delivering full, streamlined AOT builds rather than typical .NET CLR applications (and JIT compilation).
Attributes have to be at one specific spot (before the method/class declaration).
Functions and builders you can compose. You can, for example loop, over something and add multiple routes programmatically. For example if you load the routes from a database, it’s really hard to create attributes. You would need to compile and load assemblies on the fly, or do some reflection black magic.
I don’t know, nobody needs more the 640k of RAM, right?
Maybe you have multiple modules, and depending on the configuration the routing changes. Or feature flags, that enable a breaking api change. Or a stupid customer that pays you a million dollar for custom routes.
But what benefit do the attributes bring? You need to learn them by heart, on builders Intellisense can help you.
Well yes - if you need some kind of dynamically configurable routing then attributes aren't a good fit. I like the fact they are there right next to the relevant method...
Another thing is, that attributes totally opinionate your code. You pull in a framework into your code.
If you - for example - write one controller you want to use with multiple frameworks (ASP.NET Core or Nancy), you need one controller per framework, just for the attributes.
I always found them more annoying then helpful. Most people seem to see it that way. Most frameworks are moving away from attributes for a good reason.
btw. in .net core you can either use attributes or builders to create your routes or even more stuff. at least since (i think) 3.0.
and if that is not a great fit you can actually build your own routing by creating a middleware (btw. the endpoint routing stuff is just a middleware)
I hope this will make it easier. Reminds me of the good old Nancy times.