> Only if you don't know C# or asp.net (or bootstrap). In which case: why would you be working for an organization which does?

You've never taken a job working in a language you don't know yet? Anecdotally this is a common thing. In fact, my most recent job hired me to write C# with nothing but prior Go/Python experience.

> This kind of structured approach has fallen out of favor because it's become more popular to hire javascript and react developers straight out of boot camp who have only been taught how to code one or two things.

This comes across to me as needlessly bitter to folks with less experience than you.

> You've never taken a job working in a language you don't know yet? Anecdotally this is a common thing. In fact, my most recent job hired me to write C# with nothing but prior Go/Python experience.

So then it shouldn't be a problem for you to learn a new skill based on a very common pattern with many examples in different languages

> This comes across to me as needlessly bitter to folks with less experience than you.

If those folks are forcing the business to make tech decisions based on their lack of experience, it makes life harder for others. If you are going to choose between "should we write our backend in C# or javascript", and the decision comes down to "well our bootcamp grads don't know C# and they don't have a background in software engineering, so getting them up to speed on C# will take months", then you're willingly choosing inferior tech to make up for subpar employees

You appear to think that there is One Way to write applications and that anyone who disagrees with you doesn't know what they are talking about or has never had any experience with them.

Perhaps you should be open to the possibility that you're wrong in assuming that? Perhaps there are people who dislike these kinds of designs precisely because they have experience with them?

(hint: I wrote my first IoC container/framework about 20 years ago)

I personally find that the second example has poor readability even if you are familiar with the framework/pattern. I've worked on codebases that use each of those patterns, and I greatly prefer those where all of the routes (and ideally the auth middleware too) are defined in a single top-level routes file.

IMO it makes it much easier to get an overview of the overall functionality of the app, and to find the code which implements each route. It's also a lot more flexible if you ever need to support routes which do not fit the conventional pattern of the framework (perhaps for legacy reasons).

You can of course still use dependency injection, etc with this central route registration model.

I can understand that view, but I like to have the controller class files themselves represent the site hierarchy. Rather than looking in a file for the appropriate route, I look through the filesystem to understand the routing. I expect FooController to map to /foo (or /api/foo or whatever). I worked on a django project which did all the routing in a single location and it frequently resulted in merge conflicts between multiple developers committing changes to the file about the same time

> is how you get hundreds of poorly written spaghetti code

So what you are saying is that the IoC / Decorator approach is the way to avoid spaghetti code? That's an interesting assertion.

> You are setting yourself up for some bad tech debt in the future

You mean like being saddled with a product that depends on a large framework that fewer and fewer people want to deal with?

The way to avoid tech debt is to retain plasticity, keep more options open and not paint yourself into a corner where your choice of framework dictates how you structure entire systems.

And, of course, to hire people based on talent and ability rather than a line on their CV that promises experience with a given framework.