Por que devo usar um padrão MVC?

74

Parece que todo mundo que faz aplicativos da Web hoje em dia quer usar o MVC para tudo. Acho difícil me convencer a usar esse padrão, no entanto. Entendo que a idéia geral é separar a lógica de back-end do front-end que representa o programa. Geralmente, parece que as visualizações sempre dependem do controlador até certo ponto, o que acaba dependendo do modelo. Não vejo a vantagem de adicionar o controlador para mim. Eu já li muita propaganda sobre "é assim que os aplicativos devem ser projetados", mas talvez ainda não entenda o que deve ir aonde. Sempre que falo com outras pessoas sobre o MVC, parece que todo mundo tem uma idéia diferente do que pertence a qual categoria.

Então, por que devo usar o MVC? O que ganho com o MVC apenas separando o frontend da lógica de back-end? (A maioria das "vantagens" que vejo desse padrão são obtidas apenas pela separação da interface da implementação e não conseguem explicar o propósito de ter um "controlador" separado)

Billy ONeal
fonte
9
MVC é simplesmente uma implementação de Separação de Preocupações . Qualquer implementação servirá. Não usando seperations de preocupações tende a conduzir a uma bola grande de lama
Raynos
1
@ Raynos: Talvez. Mas não é para lá que o "hype" está indo.
Billy ONeal
3
hype obedece à curva de hype . Não deixe que isso o influencie demais. Do meu ponto de vista, o MVC é uma arquitetura sólida para o SoC e fácil de implementar. Não consigo pensar em uma alternativa sólida.
Raynos 01/09/11
a maioria dos frameworks de interface do usuário existentes firmemente ligação V e C e quando você alternar para outro que você precisa para reescrever tanto a vista e controlador (a interface de M para o que o usuário vê)
catraca aberração
Mas a Separação de Preocupações é uma propriedade do desenvolvimento de OO. Você não precisa usar um padrão MVW para implementar um código correto de Separação de Preocupações?
Bastien Vandamme 16/04

Respostas:

50

Heh. Martin Fowler concorda com sua confusão sobre o MVC:

Não acho muito útil pensar no MVC como um padrão, pois contém algumas idéias diferentes. Pessoas diferentes que leem sobre o MVC em lugares diferentes pegam idéias diferentes e as descrevem como 'MVC'. Se isso não causar confusão suficiente, você obtém o efeito de mal-entendidos do MVC que se desenvolvem através de um sistema de sussurros chineses.

No entanto, ele continua dando uma das explicações mais convincentes sobre o que motiva o MVC:

No coração do MVC está o que eu chamo de Apresentação Separada. A idéia por trás da apresentação separada é fazer uma divisão clara entre objetos de domínio que modelam nossa percepção do mundo real e objetos de apresentação que são os elementos da GUI que vemos na tela. Os objetos do domínio devem ser completamente autônomos e funcionar sem referência à apresentação; eles também devem oferecer suporte a várias apresentações, possivelmente simultaneamente.

Você pode ler o artigo completo de Fowler aqui .

Gnawme
fonte
19

Eu sinto que isso depende muito do problema que você está enfrentando. Eu vejo a separação da seguinte maneira:

Modelo - como representamos os dados? Por exemplo, como faço para passar dos meus objetos para um armazenamento persistente como um banco de dados -> como faço para salvar meu objeto 'Usuário' no banco de dados?

Controlador - o que estou fazendo? Essa é a ação que está ocorrendo e o que, em um nível conceitual, precisa ser realizado. Por exemplo, em quais estágios eu preciso passar para faturar um usuário? Nota: isso pode afetar qualquer quantidade de objetos, mas não sabe nada sobre como eles são mantidos no banco de dados.

Ver - como renderizo o resultado?

O problema que sinto que você está vendo é que muitos aplicativos da Web são uma interface CRUD (Create-Retrieve-Update-Delete) glorificada para um banco de dados. ou seja, o controlador é instruído a 'adicionar um usuário' e, em seguida, simplesmente diz ao modelo para 'adicionar um usuário'. Nada é ganho.

No entanto, em projetos onde as ações que realizam não se aplicam diretamente a mudanças no modelo de um controlador torna a vida muito mais fácil e o sistema mais sustentável.

Unk
fonte
1
"em projetos em que as ações que você executa não se aplicam diretamente a alterações no modelo" O que você quer dizer com "modelo" aqui? O banco de dados? Porque todos com quem conversei dizem que essas ações ainda pertencem a um modelo, não a controladores. (por exemplo, que os controladores só deve estar lidando com coisas HTTP ...)
Billy ONeal
O que conta como material HTTP? Eu incluiria o seguinte em um controlador: Remover a análise dos parâmetros de solicitação HTTP, verificar os parâmetros quanto à sanidade básica, determinar o que precisa ser feito, visitar objetos de modelo apropriados (para ler, escrever ou ambos), produzindo um resultado final com base nas respostas do modelo , passando isso para a visualização. Um exemplo bobo de algo unicamente um controlador seria usado para pode ser um serviço web gerar um número aleatório - neste caso, não há nenhum 'modelo' para olhar (em minha mente, pelo menos ...)
Unk
Todas essas são preocupações modelo. Mesmo "decidir o que precisa ser feito" (o "controlador frontal") é um modelo.
Billy ONeal
2
Sem mencionar que os controladores são úteis para não acoplar seus modelos às suas visualizações. Além de permitir conectar muitas visualizações a vários modelos através de um controlador.
Raynos 01/09/11
1
@ Billy: se você permitir que uma visão "mexa" com o modelo - além de consultar seus valores -, você terá visões mais semelhantes aos controladores. Penso mais em termos da encarnação Model-GUI-Mediador do MVC. O controlador faz a mediação entre o Modelo (comportamento e dados do domínio) e a GUI (representação na tela do modelo). A visualização apenas passa interações para o controlador (usuário clicou ...). O controlador decide como (se houver) deve ser chamado no modelo. Benefícios: ...
Marjan Venema
8

Você não deveria.

Deixe-me reformular isso. Você deve usar uma arquitetura que separa a lógica de suas visualizações. Se necessário, você deve usar uma arquitetura que utilize um controlador (como MVC), se houver lógica necessária que não se ajuste necessariamente a um modelo (como, por exemplo, um trecho de URL de análise de passagem de árvore).

Vindo da CI e da Yii, achei que ter um controlador dedicado era uma ideia muito legal. No entanto, ao desenvolver aplicativos com interfaces RESTful adequadas, a necessidade de um controlador para lidar com lógica não específica do modelo parece diminuir. Assim, ao mudar para o Django e depois para o Pyramid (nenhum dos quais segue a arquitetura MVC completamente), descobri que o controlador não era realmente um componente necessário para os aplicativos que eu estava construindo. Observe que as duas estruturas possuem recursos "controller'ish", como o Dispatching de URL no Pyramid, mas é uma coisa de configuração, não de runtime (como o CController no Yii).

No final do dia, o que é realmente importante é a separação da visão da lógica. Isso não apenas limpa as coisas em termos de implementação, mas também permite que os engenheiros da FE / BE trabalhem em paralelo (ao trabalhar em um ambiente de equipe).

(Observação: não desenvolvo aplicativos da web profissionalmente, pode haver algo que esteja faltando)

Demian Brecht
fonte
Eu concordo totalmente, boa resposta. O controlador nem sempre é necessário, é apenas uma estratégia para a visualização se comunicar com o modelo.
Falcon
@Falcon: Veja, essa é a minha confusão. Eu já vi mais de uma pessoa dizer que a visão não deveria falar com o controlador; que ele deve falar apenas para o modelo ...
Billy ONeal
1
Se você estiver usando uma implementação real do MVC, a visualização não se comunicará com o controlador (ou o modelo). O controlador define o estado do modelo, prepara os dados para a visualização e os envia para a visualização.
Demian Brecht
@ Demian: Eu ouvi o contrário (que os controladores não devem fazer nada efetivamente). Frequentemente. Esse é o meu maior problema com esse padrão; ninguém parece concordar com o que é.
Billy ONeal
3
Sim, eu sempre ouvi dizer que, se você tiver 10 programadores em uma sala, terá 9 definições diferentes do que é o MVC. Realmente, o ponto principal é a separação de preocupações. O que mais se passa parece ser um debate religioso.
Demian Brecht 02/02
1

Sim, a terminologia disso é uma bagunça. É difícil falar, porque você nunca entende exatamente o que alguém quer dizer com os termos.

Quanto ao motivo de um controlador separado, o motivo pode depender de qual versão do controlador você está falando.

Você pode querer um controlador, porque ao executar testes, a exibição possui vários widgets que você não escreveu e provavelmente não deseja testar. Sim, você separou a implementação da herança, para poder usar um esboço ou simulação para testar outras coisas, mas quando você testa sua própria visão concreta, é mais difícil. Se você tivesse um controlador que não tivesse nenhum widget executando o mesmo código, poderia testá-lo diretamente, e talvez não fosse necessário testá-lo via script.

As outras versões são mais difíceis de mostrar para um benefício concreto. Eu acho que é principalmente uma questão de separação de preocupações - separe as preocupações visuais puras da GUI da lógica que se aplica à GUI, mas não faz parte do modelo de negócios (coisas como, traduzir atualizações do modelo no qual os widgets devem estar visíveis). Mas, na prática, é provável que as duas classes sejam tão fortemente acopladas (mesmo que se comuniquem por meio de interfaces) que é difícil ficar muito chateado ao mesclá-las em apenas uma visualização, e fique de olho nas maneiras pelas quais a funcionalidade pode ser mais reutilizável se eles foram divididos.

psr
fonte
0

Simplificando: separação de preocupações. Além de toda a conversa sobre a maneira "correta" de fazer as coisas, ter um código mais limpo, etc., você pode apenas dizer que o MVC permite que você reutilize seu código com mais facilidade. Basicamente, você programa seus modelos e controladores e pode usá-los indistintamente em um aplicativo Web, aplicativo de mesa, serviço, em qualquer lugar, sem muito esforço.

AJC
fonte
2
Isso não é diferente do que simplesmente definir uma camada de interface do usuário e uma camada funcional. Você não explicou por que o bit do controlador é necessário.
Billy ONeal
-3

Bem, o motivo básico para o uso de uma estrutura MVC aparece em uma configuração do setor, onde um único processo de trabalho, um único modelo é seguido para o desenvolvimento de qualquer aplicativo. Portanto, se o projeto passar de um módulo de uma organização para outra, é muito mais fácil fornecer uma melhor compreensão do cenário de trabalho. Incorpora clareza de trabalho.
Enquanto você, como indivíduo, teria uma abordagem diferente para sua aplicação, você, ao trabalhar de maneira combinada com um associado, discutiria primeiro e chegaria a um modelo comummente aceito pelos dois (você e seu associado). Nesse caso, ele separa as responsabilidades atribuídas a você e seu associado, respectivamente, com uma margem distinta.

ikartik90
fonte
-3

Eu acho que o MVC é usado apenas como um chavão por teóricos que são gerentes. No entanto, dito isso, a iteração atual da web com design responsivo predominante em HTML5 e tentando criar uma única linha de programação de banco de dados que funcione na web e em um iPhone se presta às idéias gerais do MVC. A tecnologia de front-end da Web está literalmente se movendo na velocidade da luz no momento com o Jquery, novas iterações de controle de CSS, enquanto o lado do servidor está se movendo no ritmo de um caracol.

Eventualmente, tudo no servidor será apenas serviços ou "applets" que bombearão os dados para o front-end e, dependendo do tipo de cliente que você possui, esses dados serão consumidos e exibidos de maneira diferente. Nesse sentido, o MVC faz sentido.

Nesse sentido, acredito que no mundo real atual, o MVVM é realmente um "padrão" melhor ou o que você quiser chamá-lo de controlador, porque um controlador sempre precisa voltar ao modelo para mudar a visualização e isso é lento . No padrão MVVM, o ViewModel pode fornecer atualizações imediatas para a visualização. Além disso, o modelo MVVM promove os princípios de design do RESTful IMHO.

Michael Barber
fonte
essa é apenas sua opinião ou você pode apoiá-la de alguma forma?
gnat
3
(não diminuiu o voto) Bem, tem sido um chavão que dura mais de 40 anos, se for.
Billy ONeal
2
Gostaria de encorajá-lo a colocar algumas pesquisas adicionais sobre as origens do padrão MVC e os padrões adicionais gerados, como MVP e MVVM. Há muito mais história no padrão do que o atual buzzwordiness levaria você a acreditar.
1
Da história do Model View Controller : "O MVC foi inventado na Xerox Parc nos anos 70, aparentemente pela Trygve Reenskaug. Acredito que sua primeira aparição pública foi no Smalltalk-80. Por um longo tempo, praticamente não houve informações públicas sobre o MVC, mesmo no Smalltalk O primeiro artigo importante publicado no MVC foi "Um livro de receitas para o uso do paradigma da interface do usuário do model-view-controller no Smalltalk -80", de Glenn Krasner e Stephen Pope, publicado na edição de agosto / setembro de 1988 do JournalOfObjectOrientedProgramming (JOOP). "
Existem muitos chavões muito mais importantes, como o KISS, que existem há mais tempo e recebem muito menos atenção.
Michael Barber