Como programador sério, como você responde à pergunta O que é MVC?
Na minha opinião, o MVC é um tópico meio nebuloso - e, por esse motivo, se seu público é um aprendiz, você é livre para descrevê-lo em termos gerais que dificilmente serão controversos.
No entanto, se você estiver falando com um público experiente, especialmente um entrevistador, é difícil pensar em uma direção a seguir que não arrisque uma reação de "bem, isso não está certo! ...". Todos nós temos experiências diferentes no mundo real e nunca encontrei o mesmo padrão de implementação MVC duas vezes.
Especificamente, parece haver divergências quanto ao rigor, definição de componentes, separação de peças (qual peça se encaixa onde), etc.
Então, como devo explicar o MVC de maneira correta, concisa e incontroversa?
fonte
Respostas:
MVC é uma arquitetura de software - a estrutura do sistema - que separa a lógica do domínio / aplicativo / negócio (o que você preferir) do restante da interface do usuário. Isso é feito separando o aplicativo em três partes: o modelo, a visualização e o controlador.
O modelo gerencia comportamentos e dados fundamentais do aplicativo. Ele pode responder a pedidos de informações, responder a instruções para alterar o estado de suas informações e até mesmo notificar observadores em sistemas controlados por eventos quando as informações mudam. Pode ser um banco de dados ou qualquer número de estruturas de dados ou sistemas de armazenamento. Em resumo, são os dados e o gerenciamento de dados do aplicativo.
A visualização fornece efetivamente o elemento da interface com o usuário do aplicativo. Ele renderizará os dados do modelo em um formulário adequado para a interface do usuário.
O controlador recebe entrada do usuário e faz chamadas para modelar objetos e a visualização para executar ações apropriadas.
Em suma, esses três componentes trabalham juntos para criar os três componentes básicos do MVC.
fonte
Analogia
Expliquei o MVC ao meu pai assim:
MVC (Model, View, Controller) é um padrão para organizar o código em um aplicativo para melhorar a capacidade de manutenção.
Imagine um fotógrafo com sua câmera em um estúdio. Um cliente pede que ele tire uma foto de uma caixa.
A caixa é o modelo , o fotógrafo é o controlador e a câmera é a vista .
Como a caixa não conhece a câmera ou o fotógrafo, é completamente independente. Essa separação permite ao fotógrafo andar pela caixa e apontar a câmera para qualquer ângulo para obter a foto / visão que deseja.
Arquiteturas não MVC tendem a ser fortemente integradas. Se a caixa, o controlador e a câmera fossem o mesmo objeto, teríamos que nos separar e reconstruir a caixa e a câmera sempre que desejássemos obter uma nova visualização. Além disso, tirar a foto sempre seria como tirar uma selfie - e isso nem sempre é muito fácil.
Explicação detalhada
Foi só depois de ler a seguinte pergunta / resposta maillist que eu senti que tinha entendido o MVC. Citação: https://mail.python.org/pipermail/python-list/2006-January/394968.html
fonte
MVC é principalmente um chavão.
Costumava ser considerado um padrão, mas sua definição original de 1979 foi embotada, repassada, mal interpretada, tirada do contexto original. Foi mal redefinido a ponto de parecer uma religião e, embora isso certamente ajude seus cultistas de carga a defendê-la, seu nome não se associa mais a um conjunto sólido de diretrizes . Como tal, não pode mais ser considerado um padrão.
O MVC nunca foi concebido para descrever aplicativos da web.
Nem sistemas operacionais modernos, nem idiomas.
(alguns dos quais realmente redundaram a definição de 1979)
Foi feito para. E não deu certo.
Agora lidamos com um híbrido obscuro de web-mvc que, com seu status de palavra-chave horrível, má definição e tendo programadores semi-analfabetos como um público-alvo, faz uma publicidade muito ruim aos padrões de software em geral.
O MVC, portanto, tornou-se uma separação de preocupações destiladas para pessoas que realmente não querem pensar muito sobre isso.
Os sites / aplicativos da web nos anos 90 realmente não costumavam aplicar a separação de preocupações.
Eles eram pedaços horríveis de código de espaguete misturado.
As alterações na interface, os reprojetos e os rearranjos de dados foram incrivelmente difíceis, caros, longos, deprimente e malfadados.
Tecnologias da Web como ASP, JSP e PHP tornam muito fácil misturar as preocupações de exibição com os dados e as preocupações de aplicativos. Os recém-chegados ao campo geralmente emitem bolas de código inextricáveis, como nos velhos tempos.
Assim, um número crescente de pessoas começou a repetir "use MVC" em loops intermináveis em fóruns de suporte. O número de pessoas expandiu-se a ponto de incluir gerentes e profissionais de marketing (para alguns o termo já era familiar, desde os tempos da programação da GUI, na qual o padrão fazia sentido) e que se tornou o gigante de um chavão que devemos enfrentar agora .
Tal como está, é senso comum , não uma metodologia .
É um ponto de partida , não uma solução .
É como dizer às pessoas para respirar ar ou fazer abdominais , não uma cura para o câncer .
fonte
It's a fancy word for pre-existing concepts that didn't really need one.
E qual padrão / arquitetura de design não se encaixa nessa descrição?The data model is handled one way, the view in another, the rest is just named "controller"
+1A melhor maneira de defini-lo é ir aos escritos originais de Trygve Reenskaug , que o inventou: http://heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html
Este artigo, em particular, é geralmente considerado o texto de definição: http://heim.ifi.uio.no/~trygver/1979/mvc-2/1979-12-MVC.pdf
fonte
MVC é um padrão de design usado para isolar a lógica de negócios da apresentação.
Difere de muitos outros padrões de design pelo fato de geralmente não ser implementado de forma sucinta, mas é a base de uma estrutura.
Embora um aplicativo que implemente um padrão de estratégia seja apenas um pequeno detalhe, dizer que um aplicativo da web usa o padrão de design do MVC é muito definidor de sua arquitetura .
fonte
MVC é um design de software que separa os seguintes componentes de um sistema ou subsistema:
fonte
Eu diria que MVC é um conceito ou uma família de padrões semelhantes.
Acho que vale a pena ler este artigo. Arquiteturas de GUI por Martin Fowler
fonte
Primeiro, você precisa determinar quem é o autor da pergunta e que tipo de resposta ele está procurando. Você responde a essa pergunta com outra pergunta, como "Em que sentido?"
Você pode perguntar se eles estão se referindo ao MVC em geral, uma implementação específica do MVC (por exemplo, asp.net MVC, spring MVC, smalltalk MVC, etc.), o que é tecnicamente, o que é filisoficamente (sim, tem um filosofia também), etc.
Se essa é uma pergunta em um teste e você não pode pedir ao solicitante que esclareça, precisará adivinhar com base no contexto.
Uma resposta boa e simples é:
Você também pode dizer:
Mas, no final, você será julgado se dará a resposta que eles esperam. A única solução para o problema é descobrir que tipo de resposta eles estão esperando.
fonte
Aqui está o que eu diria sobre isso. Eu tentaria explicá-lo em termos de aplicativos móveis, porque é com isso que estou mais familiarizado e porque acho que não o entendi completamente antes de começar a fazer aplicativos móveis.
Vamos pegar o Android, por exemplo.
Camada de apresentação, ie. A interface do usuário pode (na maioria das vezes é) ser especificada inteiramente em xml. Para simplificar, digamos que um arquivo xml descreva uma tela no aplicativo. O arquivo XML especifica controles, layout dos controles, posicionamento, cores, tamanho, rótulos de strings ... tudo relacionado à apresentação. No entanto, não sabe nada sobre quando será chamado, quando será colocado na tela. Será um layout independente ou parte de um layout maior? Aí está: sua visão perfeita .
Agora, obviamente, a visualização precisa ser colocada na tela em algum momento, então como deve ser feito? Seu CONTROLADOR , no Android, chamado Atividade. Como o nome diz, atividade faz alguma atividade. Mesmo que seu único objetivo seja exibir a vista definida na etapa 1, ele executará alguma ação. Portanto, a atividade busca uma exibição e a exibe na tela. Como a view não sabe nada sobre atividade, da mesma forma a atividade não sabe nada sobre a apresentação real. Nós (os programadores) podemos reorganizar o layout da exibição várias vezes, sem alterar nem uma linha de código em nossa atividade.
Agora, não há muita utilidade em apresentar seu layout xml brilhante e bem definido sem realmente fazer algo. Digamos que queremos armazenar os dados inseridos pelo usuário. A atividade precisa enfrentar esse processo, desde os dados do usuário até os repassar para outra pessoa para lidar com eles (processar, armazenar e excluir). Para quem vai passar? Bem, para um MODELO . Eu gosto de pensar em um modelo como puro. classe java que não sabe nada sobre o contexto de aplicativos em que vive. (Na prática, quase nunca será esse o caso).
Digamos que eu tenho uma classe Pessoa que possui três propriedades: nome, endereço, idade. Meu layout definido em XML possui 3 campos para entrada do usuário: nome, endereço, idade. Minha atividade pega os três valores da entrada do usuário, cria um novo objeto Person e chama algum método nele que sabe como lidar com alguma lógica específica de Person. Aí está. Controlador de visualização de modelo.
fonte
Eu sempre começo dizendo a eles que o padrão não é novidade e existe há muitos anos ... é nesse ponto que eles me dão uma aparência inquisitiva e BAM !, eles são viciados:
E então eu falava sobre os vários pontos, como as respostas anteriores, mas acho importante também ser contextual, como JB King disse, ASP.NET MVC etc,
fonte