“Your .NET controllers should be thin”
The ever-repeated platitude with 3 metric tons of baggage to unpack.
Why should they be thin? How does tha...
For further actions, you may consider blocking this person and/or reporting abuse
While this is sort of OK, it's better to say what is good to do in a controller and how to do it, instead of what isn't - like when you talk to a toddler - saying "NO" is like a white noise to them - they stop for a few seconds or cry if you say that loud, but a few minutes later they try again.
Let me argue about the NOs - adding too much abstractions and following these rules (and other design patterns) usually leads to layer after layer of abstractions and getting to the bottom of such code is basically a pain in the neck. Even bigger fun is adding a new column in the database, then in the data model, then in another intermediate business object, then in the response model, then in another request model, ah even one more intermediate object and at that point I usually want to get drunk... in a "quick-and-dirty php-style code" (and I hate php in my guts, I assure you), it will be literally 15-20 lines of code all that and it will be in a single file, where you can see all of it in one place, instead of scattered in 3 different projects and 12 different files where half of the code is pointlessly mapping fields from one object to another.
A program is a set of instructions for the computer to do something and we usually have to maintain this piece of s**t for years, so the most important part of it is to be obvious and easy to understand and change. This is why in theory the single responsibility principle sounds good and you may think - hey the code is great - I see a small function and I can see what it does. Then you find another one, then another one and 8 levels deep in the function hierarchy on the 5th file you opened you realise, that at this point you need a sheet of paper to write down what the hell you are doing, how the objects "talk" to each-other, where is the factory, that created an object with the required interface and so on and so on.
Interesting, but as not a .NET developer, I’d have liked to see examples of where you should put that code instead.
Thanks William, and yes actually I use both!