It depends.

I think it's best to categorize by rule type to be clearer.

Data Validations

Yes, it is wrong. Data validation is a characteristic of the data type, therefore the Model responsibility.

Verification of existence of referenced registry

No. It is the function of Controller to check if the record of another table actually exists before making any assignment. The Controller's responsibility is to harmonize the data between Models and also between the presentation layer.

Data audit (log)

It depends. If the type of data to be audited follows a format and data pattern, it is best to use a library (such as those that work with aspects) that intercept the data, or a ActionFilter .

Otherwise, there is no problem in using this in the Controller as long as your Controller has adequate support for transactions.

Mount Views

Yes, very wrong. The Controller should only provide the data for Views . Never mount HTML, for example.

This does not apply if the result returned by a Controller is a file (for example, an image or a PDF), or some standardized data format (JSON, XML, and so on). onwards).

There is a caveat about PDFs. There is a package called RazorPDF2 that assembles PDFs at View level. This package is my own, so any doubt or if you want to report bugs, you can contact me through the means available here on the site (mention, chat, etc.).

Advantages

• Simple and transparent. The rule you see is the rule actually executed;
• Fast to develop;
• It can span a single transactional scope, unlike Services , whose isolation requires calling multiple repositories, unnecessarily increasing the code.

Disadvantages

• If your system is large, the rules of each Controller method can be huge if responsibilities are not well segmented. For example, a method that executes multiple business rules, logs in, etc.
• If a large set of rules needs to be run across multiple Controllers , using such an approach can make the code rather repetitive (personally speaking, just for these cases I see the use of a service layer as something positive).

Preferably avoid doing this, of course there may be exceptions.

There are several reasons why, if you have the same rule that will be used by another controller ? Will you duplicate? So moving to another class that will often be a Service will make it easier for you to reuse.

You are hurting the principle of sole responsibility of SOLID . Basically you're letting your controller do more things than it should.

But to not seem too inflexible, if you're just making a phone book this might not be a problem, but when your phone book begins to grow it's time to follow good practices that will avoid headaches and macaroni codes.