Explain Model View Controller

Minha experiência no desenvolvimento de sites dinâmicos é limitada principalmente a servlets Java. Eu usei o Tomcat para desenvolver vários servlets Java e não hesitaria em dizer que sou razoavelmente competente com essa tecnologia, bem como com HTML / CSS / Javascript do cliente no front-end.

Quando penso em "site dinâmico", penso: o usuário solicita uma URL com uma string de consulta, o servidor recebe a consulta e passa a produzir HTML dinamicamente para responder à consulta. Isso geralmente envolve a comunicação com um banco de dados para buscar dados solicitados para exibição. Esta é basicamente a idéia por trás do doGetmétodo de um Java HttpServlet.

Hoje em dia, porém, estou ouvindo cada vez mais sobre estruturas mais recentes, como Django e Ruby on Rails, que aproveitam a arquitetura "Model View Controller". Eu li vários artigos que explicam o MVC, mas estou tendo problemas para entender realmente os benefícios. Entendo que a idéia geral é separar a lógica de negócios da lógica da interface do usuário, mas não vejo como isso é realmente diferente da programação da web normal. A programação da Web, por sua natureza, obriga a separar a lógica de negócios (programação do servidor de back-end) da programação da interface do usuário (HTML ou Javascript do cliente), porque os dois existem em esferas de programação totalmente diferentes.

Questão: O que o MVC oferece sobre algo como um servlet Java e, mais importante, o que exatamente é MVC e como é diferente do que você faria normalmente para desenvolver um site dinâmico usando uma abordagem mais tradicional, como um servlet Java (ou mesmo algo mais antigo como CGI)? Se possível, ao explicar o MVC, forneça um exemplo que ilustra como o MVC é aplicado ao processo de desenvolvimento da Web e como é benéfico.

Primeiro eu acho que é melhor falar sobre o que é MVC Architecture e depois aprofundar o modo como você está programando atualmente.

A MVC Architecture é uma maneira de organizar o fluxo de trabalho dentro de um sistema de sotfware, pense nisso como uma maneira em camadas de implementar o comportamento do sistema. Essas camadas são:

1. Modelo : representa seu modelo de dados, é o núcleo do sistema onde todas as informações relacionadas a ele devem ser localizadas. Por exemplo: se você estiver planejando um jogo, precisará de jogadores, regras, obstáculos e alguma lógica relacionada às interações desses elementos, como: Jogadores devem poder classificar obstáculos quando algum conjunto de regras se aplicar.

   O Modelo é o primeiro que você deve pensar, porque será o centro de seus aplicativos .

2. Controlador : É aqui que a mágica acontece e onde a Arquitetura em Camadas encontra o Paradigma Orientado a Objetos que se destinava a ser usado. Aqui é onde você implementa como o sistema reage quando algum usuário do aplicativo solicita algo sobre o aplicativo e vai para a interface do usuário.

   O Controller deve ser capaz de lidar com os Objetos de Modelo, fazer operações com eles para alcançar o que o usuário solicitou e, em seguida, delegar o resultado na Camada de Visualização correspondente para devolvê-lo ao nosso usuário.

3. Visão : Este é o ponto inicial e final das interações do usuário. Aqui é onde você define como os usuários interagem com o aplicativo. Atualmente, é bastante comum os usuários tentarem acessar, por exemplo, aplicativos da web de diferentes tipos de mídia, como: telefones celulares, mesas, computadores, laptops etc.

   Geralmente, cada tecnologia precisa de uma linguagem diferente para criar a exibição. Imagine que seu Modelo de Dados e a maneira como o modelo interage e como você processa essas interações são todos codificados, não há absolutamente nenhuma maneira de reutilizar seu código de uma maneira que não seja CopyPaste . O resultado é um código que cheira e perde muito tempo adaptando o sistema HOLE.

   A virtude de ter a View em uma camada separada permite trabalhar independentemente do modelo em que estamos trabalhando . Nós só precisamos saber como devemos renderizar a lista de objetos que o controlador está nos enviando. Como ele gerou é completamente trivial

Então, finalmente, temos um Modelo independente que pode ser adaptado conforme acharmos melhor de acordo com nossas necessidades atuais (hoje eu preciso lidar com um jogo Monouser sem regras, amanhã eu quero jogar com amigos e agora com seu multiusuário, e assim por diante) isso não depende de como vamos renderizá-lo ao usuário. Então, um controlador que captura os usuários solicitados provenientes de uma visualização, processa Objetos Modelo e, em seguida, devolve as informações à Visualização para renderizá-las.

De volta à primeira pergunta que você fez: Como você pode ver (espero), o MVC é uma maneira de fazer as coisas e não uma TECNOLOGIA para criar software. Você pode usar seus Servlets java e implementar uma MVC Achitecture sob ela.

Aqui está um site de exemplo de perguntas e respostas usando uma arquitetura MVC para esclarecer um pouco

Para responder sua pergunta

What does MVC offer over something like a Java servlet

MVC é um padrão, não uma tecnologia. Portanto, o padrão pode ser aplicado quando você estiver programando também com Servlets.

Deixe-me tentar explicar o padrão MVC com os próprios Servlets. Portanto, o que você está tentando fazer ao falar sobre a aplicação do MVC é separar o Modelo (a lógica de negócios), a visualização (a lógica de apresentação) e o Controller (o Servlet do controlador que delega o controle para a lógica de negócios apropriada).

Nesse caso, o MVC não se trata apenas de separar os negócios da camada de apresentação e da camada do controlador, mas a camada de negócios nem sabe que existe um controlador ou apresentação.

As principais estruturas em Java, como o Struts, seguem esse padrão. Eu acho que você entendeu errado o conceito. Você pode ler mais sobre isso na internet.

O MVC é realmente fácil de entender, é apenas um padrão de design; no entanto, vi que o mais difícil / supervisionado é a parte do modelo.

• Modelo : seus dados (não exclusivamente seu banco de dados !, o modelo pode até ser um arquivo ini ou xml ou dados de um serviço da web). As classes de modelo têm o objetivo de definir, montar e manipular dados. Leia o excelente artigo chamado " O M no MVC: por que os modelos são incompreendidos e não apreciados ". O modelo deve ser acessado apenas pelo controlador.
• Exibições : O código da sua GUI (apresentação). Deve acessar apenas o controlador
• Controlador : sua lógica. Lida com a comunicação entre modelo e vista.

O conceito Model-View-Controller não é novidade. Tudo começou com Smalltalk por volta de 1979.

Na sua essência, o MVC é uma maneira de organizar as responsabilidades do seu código, para que ele seja modular, previsível e robusto.

A separação permite as seguintes liberdades:

• Capacidade de evoluir o modelo sem afetar a lógica do aplicativo ou exibir os dados
• Capacidade de alterar a lógica de negócios sem afetar o modelo (por exemplo, adicionar novas etapas etc.)
• Capacidade de representar o modelo de várias maneiras diferentes

Com cuidado, é possível projetar o modelo e o controlador para substituir completamente um aplicativo de desktop por um aplicativo da Web como front-end.

Mais recentemente, a abordagem Ruby on Rails para MVC introduziu alguns conceitos mais recentes que foram copiados em quase todas as estruturas de aplicativos da web estilo MVC. Isso incluiu os conceitos de "Convenção sobre configuração", mapeamento de ações do controlador para métodos de classe e roteamento de solicitações de URL para o código subjacente.