The business logic should not go in your Models Views or Controllers. There should be a separate Business Logic Layer ; the sole purpose of this layer is to handle your business logic. This is more in-line with SOLID.
If you were to put your business logic in M V or C, you end up with code that is difficult to test / reuse.
What about putting the logic in the Models?
That is a bad solution.
You will end up in a Dependency Hell where objects rely on objects.
Even if you have a dead simple function, you'll still have to satisfy all the dependencies to call it.
It will also cause unnecessary and unused data to be passed around for no reason. This could also affect performance depending on how bad it gets.
I should also mention that unit testing becomes a pain in the a** because you have to mock multiple objects just to test a simple function.
Principles of Clean Code Applicable
- Classes / Functions take only what they need to get the job done.
- Functions should take 3 parameters or less if possible
- Name classes / functions / variables intelligently (follow Microsoft's standards)
- Do not couple business logic to Model View or Controller
Controllers
In your controller, you should be able to use dependency injection to inject the business logic layer. Make sure you controller is only used to route information to the business logic layer. The controller should NOT have business logic directly in it. Any validation needs to be handled by IValidatable on the Model. Any business logic needs to be routed to a separate layer.
