Segundo o livro Patterns of Enterprise Application Architecture, o controller do MVC é responsável pela lógica de apresentação da view. No mundo ideal, ele serviria como uma implementação do Strategy Pattern pra view. O livro chega a mencionar que poderiam existir 2 controllers pra uma mesma view, um para quando ela for editável e outro para quando não for. Mas, na prática, geralmente implementam-se apenas 1 controller por view.

Mas e as regras de negócio? Bom, quando a gente fala de MVC, acredito que a confusão está justamente no papel da model, que segundo o livro, é de conter as regras de negócio E de acesso a banco de dados, por exemplo. Digo que a confusão vem daí, pois quando nos aprofundamos em conseitos como SOLID, percebemos que essas duas responsabilidades são completamente distintas e acabamos levando as regras de negócio para o controller.

Eu acredito que muitos sistemas tenham adotado uma "camada de serviço" (coloco entre aspas pois não é o Service Layer Pattern) por conta dessa confusão. Nessa camada estão os objetos que "servem" as regras de negócio pro controller e utilizam as models como dados (e acesso à base de dados).

No mundo ideal (na minha visão), as views são templates, as models são as classes com regras de negócio (implementação do Domain Model) e os controllers são os instanciadores de models e views. Mas aí a gente adiciona mais algumas camadas no modelo a depender do projeto, como a camada de acesso à base de dados (separada das models).

Vocês acham que faz sentido essa minha visão de "mundo ideal"?