I decided to answer because there is no consensus on this. This indicates that there are problems in the MVC pattern. When something is good, everyone agrees.

• Is business model handling a bad practice?

  Here the answers indicate that it is in the model , except for some very strong reason. All users with good reputation here on the site.

• Implementing a "thin" controller

  Response with multiple votes indicates that controller is not the right place

• Business Rules in the Database - what are the advantages and disadvantages?

  Here we discuss whether the business rule should be in the database or not. Well, if there are a lot of people who think it should be in the database, then if it's in the application, the closest to the database is the model and not the controller .

• What are Application Rules and what are the differences in relation to Business Rules?

  p>

  In this shows the difference between business rule and application rule. Maybe the confusion is because some people consider the business rule to be the rule of application. The latter is in the controller . But we're talking about business rule.

• In an MVC project, where should I leave the enums?

  One more showing that you have to know what you are doing for each thing

• Which application layer is geared towards processing more complex and complex business rules?

  Here in an answer, the accepted and most voted, speaks to create an extra layer. That's not very MVC, right? Anyway it is not to use in controller . There's another one that goes the same way, though it's a bit confusing to say so.

• Which pattern is used to validate business rule?

  We have an answer that says clearly that it should stay in the model and another that goes to other layers that are not part of the MVC but it was the person who said the first question that was to put in the < in> model .

• Where should the business rule stay in the MVC standard?

  Now it's complicated because the same person who answered there in the previous one is now saying that it is to put in controller . There is another answer well voted there that speaks that depends. From what I understand goes by the way that people get confused business rule with application rule, but talk in models, so it seems to tend to the same as we saw before. And it has a third well voted that shows that depends on the case. It confuses business rule with application rule. But it was answered by the same person who answered how to differentiate one from the other. If it's a business rule, can you trust view to do it? You can even have control of what the view is in the application.

• Is it wrong to leave business rules in controllers?

  In this there is a new depends. My understanding was that you should put in the controller unless it gets too big (?!?!). The other response goes by the same path indicating that if the system is small it can by controller . I find it very strange that the decision depends on the size of the system. What I even think is that if the system is small you should not use MVC. There are those who do not use MVC even on large systems, and it does very well with this. But changing the pattern according to the size of the system is weird.

  

In Java, the business rule stays in the controller

Is it really? Do you have reference on this? The whole Java? It seems to me an assertion that does not hold in the form presented. But I believe that somewhere must say that it is so. Is the source reliable? Do you have other reliable people to confirm this? Others that contradict? Are they really reliable?

Conclusion

You may be thinking that RoR is different. Yes, it may be, but does the MVC change according to the language? Can not. That's what I'm talking about, each one went by a path.

So the simple answer is that you should do what seems best to you. But everything indicates that almost everyone agrees that the business rule goes in model and that to a lesser extent there is some agreement that the application rule should go in controller or view , according to need and complexity.