Achei realmente interessante. Pra mim faz sentido também, embora temos o conceito original de que toda regra de negócio fique estritamente no Controller.
Poderia dar um exemplo de como seria isso ?
Respondendo a "Interessante, eu vejo o Controller onde o local..." dentro da publicação Como você explicaria arquitetura MVC para um leigo?
1
3
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"?
1
Faz total sentido! Até por conta do reuso do model, onde um mesmo Model pode existir em vários lugares, enquanto não vejo isto se repetindo com o Controller. Vejo que o Controller deve usar o Model e injetar isso na View, seja o que esta "View" for.
Por exemplo, no TabNews, o model Content responsável pelso conteúdos é usado tanto no Controller da API, quanto na geração das páginas estáticas (dentro do getStaticProps, e que seria análogo a um Controller da View das páginas).