Model -> Onde ficam as classes que modelam as entidades do sistema... Ex: Cars, Users, Payments e etc... View -> Onde os dados serão exibidos o frontend... html, vuejs, angular, reactjs, javafx, cli e etc... Controller -> Onde vai estar as regras de negócio e demais serviços lógicos do sistema, ou seja, as funcionalidades...
Interessante, eu vejo o Controller onde o local que você usa as regras de negócio que estão no Model, por isso você pode usar o mesmo model em vários lugares e com isso carregar consigo as mesmas regras de negócio. Então as "regras" que estão no Controller são sobre como usar os Models, em qual sequência e quando.
Acha que faz sentido?
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 ?
Segundo o livro [Patterns of Enterprise Application Architecture](https://www.amazon.com/Patterns-Enterprise-Application-Architecture-Martin/dp/0321127420), 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](https://en.wikipedia.org/wiki/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](https://en.wikipedia.org/wiki/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](https://en.wikipedia.org/wiki/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"?
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).