Como você explicaria arquitetura MVC para um leigo?
Estou iniciando os meus estudos e busco entender esses termos, claro que já vídeos na internet, porém acho interessante ver o ponto de vista de outras pessoas.
2
3
Excelente pergunta e me veio uma idéia aqui que eu ainda não explorei, por isto ela está crua, mas veja se isto irá lhe ajudar de alguma forma.
A idéia faz uma analogia sobre alguém pegar uma informação na sua mente e com uma caneta escrever algo em um papel para que outras pessoas possam ver, onde nesse caso:
| O que? | Onde? |
|---|---|
| O que deve ser escrito | Model |
| Caneta | Controller |
| Papel | View |
Vou continuar pensando para ver se essa analogia faz sentido, pois o model não trata necessariamente da informação em sí, mas das regras de negócio (que no fundo, são informações) 🤝
1
Ah, sim. Ótima analogia, me ajudou a absorver melhor o que eu já tinha visto em aula e em vídeos. Obrigada <3
2
É uma arquitetura onde são conectados as visualizações, dados e controladores. Com esses três pilares você consegue montar uma aplicação desde o frontend até o backend.
Começando pelo Model, ou modelos: esses são os lugares onde ficam as modelagens de dados, ou seja, as estruturas onde as informações ficarão armazenadas, normalmente em um banco de dados relacional, mas existem outros tipos de bancos e tipos de armazenamento também. Com os models, normalmente através de um repositório (repository), você consegue dizer aos controllers como acessar, atualizar, criar, deletar e fazer vários tipos de manipulação.
Mas por si só os models não deveriam executar mais funções além das que estão relacionadas a sua base de dados, daí que entram os Controllers. Após executar a sentença com os dados obtidos através da estrutura do model, você consegue executar diversas linhas de código para tratar, validar, retornar ou seja lá o que quiser fazer. Então os controladores são mais focados em executar os serviços e preparar tudo o que for preciso para então enviar à tela. Entenda "à tela" como qualquer lugar onde o dado pode ser visto, seja um navegador, aplicativo ou um terminal.
Por último vem as Views, que são literalmente onde os dados serão exibidos para uma pessoa. Porque não adianta nada fazer tudo por trás dos panos se não com quem compartilhar isso né? Então a view recebe normalmente os dados já tratados pelo controller ou então um conjunto de dados para serem tratados na tela. A view não deve possúir lógica de negócio dentro dela (no meu ponto de vista), mas apenas lógicas de visualizações, por exemplo: "existem usuários? Se sim liste-os, se não mostre um estado vazio".
Com esse modelo o reaproveitamento de código é enorme, por isso vale muito a pena se aprofundar nele! Isso tudo aqui veio da minha cabeça, era o que eu ficava repetindo pra mim mesmo quando minha mente queria esquecer o que é MVC haha
1
Sensacional! Consegui entender do ínicio ao fim. Vale muito a pena se aprofundar nisso, obrigada por contribuir com os meus estudos!! <3
1
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...
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).