Keep the view decoupled from the controller. The controller serves data and the view template decide what to do with it.
Model–view–controller (MVC) is a software architectural pattern for implementing user interfaces. It divides software application into 3 interconnected parts.
The view is only for display.
The model consists of application data, business rules, business logic and functions.
The controller contains application logic and accepts input and coordinate view and model.
fat models and skinny controllers
The business logic should be placed in the model, and we should be aiming for fat models and skinny controllers.
As a start point, we should start from the controller logic. For example: on update, your controller should direct your code to the method/service that delivers your changes to the model.
In the model, we may easily create helper/service classes where the application business rules or calculations can be validated.
A conceptual summary
-
The controller is for application logic. The logic which is specific to how your application wants to interact with the "domain of knowledge" it belongs.
-
The model is for logic that is independent of the application. This logic should be valid in all possible applications of the "domain of knowledge" it belongs.
-
Thus, it is logical to place all business rules in the model.
Business rules go in the model.
Say you were displaying emails for a mailing list. The user clicks the "delete" button next to one of the emails, the controller notifies the model to delete entry N, then notifies the view the model has changed (in .NET MVC this basically means passing the view the updated model and re-rendering the view).
Perhaps the admin's email should never be removed from the list. That's a business rule, that knowledge belongs in the model. The view may ultimately represent this rule somehow -- perhaps the model exposes an "IsDeletable" property which is a function of the business rule, so that the delete button in the view is disabled for certain entries - but the rule itself isn't contained in the view.
The model is ultimately gatekeeper for your data. You should be able to test your business logic without touching the UI at all.