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...
Em resposta a Como você explicaria arquitetura MVC para um leigo?
1
1
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?
1
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 ?
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).