MVC Business Logic
Business Logic should not be contained in controllers. Controllers should be as skinny as possible, ideally follow the patter:
Find domain entity
Act on domain entity
Prepare data for view / return results
Additionally controllers can contain some application logic.
So where do I put my business logic? In Model.
What is Model? Now that’s a good question. Please see Microsoft Patterns and Practices article (kudos to AlejandroR for excellent find). In here there are three categories of models:
View Model: This is simply a data bag, with minimal, if any, logic to pass data from and to views, contains basic field validation.
Domain Model: Fat model with business logic, operates on a single or multiple data entities (i.e. entity A in a given state than action on entity B)
Data Model: Storage-aware model, logic contained within a single entity relates only to that entity (i.e. if field a then field b)
Of course, MVC is a paradigm that comes in different varieties. What I describe here is MVC occupying top layer only, vide this article on Wikipedia
Today, MVC and similar model-view-presenter (MVP) are Separation of Concerns design patterns that apply exclusively to the presentation layer of a larger system. In simple scenarios MVC may represent the primary design of a system, reaching directly into the database; however, in most scenarios the Controller and Model in MVC have a loose dependency on either a Service or Data layer/tier. This is all about Client-Server architecture