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.

filipedeschampshá 2 anos

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) 🤝

videodegatinhohá 2 anos
Ah, sim. Ótima analogia, me ajudou a absorver melhor o que eu já tinha visto em aula e em vídeos. Obrigada <3
guscsaleshá 2 anos

É 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

videodegatinhohá 2 anos
Sensacional! Consegui entender do ínicio ao fim. Vale muito a pena se aprofundar nisso, obrigada por contribuir com os meus estudos!! <3
mjordandevhá 2 anos

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...

filipedeschampshá 2 anos
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?
WebStationhá 2 anos
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 ?
tenshizer0há 2 anos
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"?
filipedeschampshá 2 anos
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).