Is it wrong to leave business rules on controllers?

Asked

Viewed 1,641 times

10

I see in several code examples this, and even in the "standard" project that is created in visual studio, they leave a good part of the rule in the controller

Is it wrong? When to use it? What is the advantage and disadvantage?

asp.net-mvc-5 pattern-design
  • 1

    Good, I never knew for sure how far a rule would be from a Controller or a Model (not only in . NET)

2 answers

8


Depends.

I think it’s best to categorize by type of rule to make it clear.

Data validations

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

Verification of existence of referenced record

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

Data audit (log)

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 else a ActionFilter.

Otherwise, there’s no problem using this in the Controller, as long as your Controller has proper transaction support.

Ride Views

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

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

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

Perks

  • Simple and transparent. The rule you see is the rule actually executed;
  • Quick to develop;
  • May cover 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 method of the Controller can become enormous if responsibilities are not well segmented. For example, a method that executes multiple business rules, inserts in log, etc.;
  • If a large set of rules needs to be run in multiple Controllers, using such an approach can leave the code quite repetitive (personally speaking, just for these cases I see the use of a service layer as something positive).

  • Because it is Gypsy, as I said, I saw a good part of the rule in controllers, there are also those who create classes "Service" (What I find complicated in some parts) and in controllers are very easy to govern and even apply DI to the reposiroty

  • I see no need for the layer of Service, whereas the Controller absorbs this function well.

  • And when you need to share certain rules between entities?

  • Well, my opinion: abandon this idea of using Service, because this design is hindering the functionality of the application components.

5

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

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

You are breaking the principle of sole responsibility of SOLID. Basically you’ll be letting your controller do more things than he should do.

But not to sound too inflexible, if you’re just making a phone book it might not be a problem, but when your phone book starts to grow it’s time to follow good practices that will prevent headaches and noodle codes.

  • Just opinionated, I disagree that the specific format of ASP.NET MVC goes against SOLID, considering that the project uses a good data abstraction framework, such as the Entity Framework. If logic needs to be repeated in more than one Controller, means that the project itself is flawed, for there are two Controllers performing the same action, which does not even justify the level of routes (since it is possible to define several sets of routes). Still in time, the approach about service and repository is prolific and the gain is small in Design.

  • 1

    I did not say that the format of ASP.NET MVC goes against SOLID, if the understanding of the answer was this then I was not clear. I said that putting business rules in your controller layer will be hurting some SOLID principles among them the principle of exclusive responsibility.

Browser other questions tagged asp.net-mvc-5 pattern-design

You are not signed in. Login or sign up in order to post.