Quais são as quedas do MVC? [fechadas]

43

Eu uso o MVC / MV * desde que comecei a organizar meu código anos atrás. Estou usando há tanto tempo que nem consigo pensar em outra maneira de estruturar meu código, e todos os trabalhos que tive após ser estagiário foram baseados no MVC.

Minha pergunta é: quais são as quedas do MVC? Em que casos o MVC seria uma má escolha para um projeto e qual seria a (mais) escolha correta? Quando eu procuro alternativas MVC, quase todos os resultados são apenas tipos diferentes de MVC.

Para restringir o escopo para que isso não seja fechado, digamos para aplicativos da web. Eu trabalho no back-end e no front-end para projetos diferentes, então não posso dizer apenas front-end ou back-end.

Oscar Godson
fonte
5
Existem muitas respostas possíveis ou boas respostas seriam muito longas para este formato. Adicione detalhes para restringir o conjunto de respostas ou para isolar um problema que pode ser respondido em alguns parágrafos.
mosquito
8
Eu precisaria de uma resposta sobre qual é a sua definição de MVC antes de poder responder à sua pergunta, pois a arquitetura MVC se aplica apenas a um conjunto de problemas como está. Então, se você usá-lo no lugar errado, você tem uma queda.
Ben McDougall
1
Quanta variedade existe em seus diferentes empregos?
Jeffo
Aplicativos PHP @JeffO (back-end, sites pesados ​​que não são JS), aplicativos de front-end. Então, toda a web, mas front-end e back-end.
Oscar Godson

Respostas:

46

Você deve sempre se lembrar - o MVC é um padrão relacionado à interface do usuário. Se você estiver construindo um aplicativo complexo, deve levar tudo, que não está relacionado à interface do usuário, dos trigêmeos do MVC para outras classes, subsistemas ou camadas.

Foi o meu maior erro. Passei muito tempo entendendo essa regra simples:

  • Não espalhe um padrão MVC entre todo o aplicativo,
  • Limite-o apenas a itens relacionados à interface do usuário.

Sempre verifique se o código que você escreve está logicamente no lugar correto, o que significa que ele se encaixa logicamente na área de responsabilidade da classe em que você o inseriu. Caso contrário - mova o código para longe assim que você o entender.

Todos os padrões que você chama de alternativas ao MVC (ou seja, Model-View-Presenter, Model-View-ViewModel) são apenas uma maneira de implementar o conceito geral do MVC.

Hedin
fonte
10
na verdade, você pode implementar o MVC sempre que tiver uma camada de abstração; a API é a visão / controlador e a lógica subjacente é o modelo
aberração catraca
14
@ratchetfreak, tecnicamente falando, uma API é uma forma de interface do usuário, em que o usuário é o programador que usa a API.
ZzzzBov
@ratchetfreak: isso não seria classificado como padrão de fachada?
precisa saber é o seguinte
2
O MVC pode ser mais útil na interface do usuário, mas sua separação de preocupações dificilmente é útil apenas lá.
DougM
1
@DougM true. mais especificamente: o estilo específico de separação no MVC foi criado para aplicativos da GUI. posteriormente, o conceito foi expandido para aplicativos da web, perdendo muita especificidade. estendendo-o ainda mais aos designs de API torna-o ainda mais vago. além disso ... acho que perde a maior parte de seu valor e seria melhor começar de novo com o conceito mais básico (e universal) de separação de preocupações.
Javier
17

Na minha opinião, existem dois tipos de MVC - puros e impuros (pela falta de uma palavra melhor :)

MVC puro é o que foi introduzido na conversa fiada:

insira a descrição da imagem aqui

Destina-se a aplicativos pessoais de computação / desktop. Como você pode ver, o modelo informa as visualizações de quaisquer atualizações / alterações feitas nele. Não é assim com o MVC (impuro).

O outro MVC (impuro) que é apresentado para aplicativos da Web é mais um padrão PAC ( Presentation-abstraction-control ) em vez do MVC clássico acima. Isso é mais organização do código e separação de preocupações:

  • Modelo : Abstração para dados armazenados
  • Controle : Geralmente, o que é conhecido como camada de lógica de negócios, bem como parte do aplicativo responsável por rotear as solicitações HTTP para a lógica de negócios correspondente (aka controlador)
  • Visualizar : visualize principalmente modelos que formatam os dados do modelo e os devolvem ao cliente. O modelo NUNCA envia atualizações para a visualização, nem a visualização 'assina' para atualizações de um modelo. Seria um pesadelo. Portanto, é mais parecido com o PAC do que com o verdadeiro MVC.

Agora, veja como um aplicativo da Web geralmente é estruturado:

  1. Front-end : MVC no cliente usando estruturas como Backbone.js etc., Esta é a forma MVC 'verdadeira' em essência.
  2. Back-end : Novamente, você possui MVC / PAC (impuro) para organização de código e separação de preocupações
  3. Aplicativo Web global (para o aplicativo Web como um todo): se você possui um back-end RESTful que retorna apenas dados JSON, todo o back-end pode ser percebido como um modelo para o aplicativo cliente front-end em que o View e o Controller residem em essência.

Então, quais são algumas desvantagens do MVC ? Bem, o padrão resistiu ao teste do tempo, por isso não há muitos que importam muito além de ser um pouco 'complicado'. Veja bem, o MVC é um padrão composto - implementa o padrão de estratégia / observador e todos estão bem organizados para formar um padrão de alto nível.

Você deve usá-lo em qualquer lugar? Talvez não. Aplicativos da web extremamente complexos podem ser divididos em várias camadas! Talvez você não consiga se safar apenas das camadas View / Business Logic / Data. A estrutura / organização abrangente ainda pode ser isenta de MVC, mas apenas em nível macroscópico.

Aqui está um exemplo em que apenas o MVC por si só pode ser uma má escolha : tente projetar um sistema de controle de tráfego aéreo ou um aplicativo de processamento de empréstimos / hipotecas para um grande banco - apenas o MVC por si só seria uma má escolha. Você inevitavelmente terá barramentos de eventos / filas de mensagens, além de uma arquitetura de várias camadas com MVC em camadas individuais e, possivelmente, um design abrangente de MVC / PAC para manter a base de código melhor organizada.

Doutorado
fonte
+1 para "puro vs. impuro". embora eu prefira usar "GUI vs Web MVCs" e aponte que o GUI MVC é modular enquanto o Web MVC está em camadas . Eu realmente gostaria que o Web MVC fosse chamado de outra coisa, já que é muito diferente de "MVC puro", mas parece que é tarde demais para isso.
Javier
Eu gosto do diagrama. Ré. a redação, talvez "MVC tradicional vs MVC derivado")
197 Edwin Yip
12

O erro que muitas pessoas cometem com os padrões de design é vê-lo funcionar lindamente em um só lugar e depois tentar aplicá-lo em qualquer lugar.

Se você trabalha em um local por um tempo, pode quase namorar um pedaço de código vendo quais tecnologias / padrões / práticas de design estavam em voga na época, por exemplo, singletons / injeção de dependência / TDD etc. etc.

Quanto a onde não usá-lo. Bem, sempre que um elemento do trigêmeo MVC não se aplica. Os aplicativos de console podem não implementar uma interface. Os programas utilitários podem não ter um modelo. E, sem dúvida, se você não tem um modelo nem uma visão, não precisa de um controlador.

O problema raramente está no conceito - mais na implementação. Não importa o quão bom seja o paradigma, reserve um tempo para ver se é um bom ajuste para o problema em questão.

Robbie Dee
fonte
2
O MVC, se seguido corretamente, permite a reutilização do código. a mesma lógica por trás de um projeto de linha de comando ou utilidade pode ser facilmente um controlador idêntico de um programa maior com um modelo e visão alternativos. (tal pode não ser o código mais eficiente, mas isso nem sempre é uma preocupação.)
DougM
Console é uma interface do usuário. Apenas texto, para que sua suposição esteja errada.
GuardianX
@GuardianX Eu realmente não falei muito bem. Eu editei minha resposta para esclarecer.
Robbie Dee #
3

O MVC, como qualquer paradigma não integrante da sua plataforma de desenvolvimento, aumenta a complexidade. A desvantagem é que você pode acabar separando classes que não devem ser separadas e diminuindo a clareza de quão estreitamente vinculadas elas são. (Ou, para projetos triviais, até ofuscar seu código.)

A alternativa para o primeiro problema é separar esse código em subprojetos independentes; a alternativa para o segundo é o código não separado, na classe ou no modelo de arquivo.

DougM
fonte
+1 por mencionar projetos menores, embora eu aprecie a existência de várias escolas de pensamento aqui. Alguns diriam que, se houver uma chance de um POC evoluir para código ativo, ele deve ser escrito corretamente. Enquanto outros dizem que, em vez de arriscar perder tempo polindo algo que nunca poderia ser usado, seria melhor criar algo em conjunto e recomeçar se o projeto prosseguisse.
Robbie Dee
@Robbie: ahh !! característica fluência!
DougM
0

Meu entendimento sobre a aplicação do MVC / MV * está seguindo o princípio da Separação de Preocupações (SoC) - separando programas / códigos em seções / partes distintas para que cada seção possa abordar uma preocupação separada (Ref: http://en.wikipedia.org / wiki / Separation_of_concerns )

existem muitos benefícios ao separar as preocupações: um não afeta o outro e os desenvolvedores podem trabalhar em uma unidade sem afetar o resto, etc. & etc ... MVC não é o único padrão que segue o SoC; basicamente, o próprio OOP é um ótimo conceito para dividir as coisas em unidades.

MVC / MV * são muito úteis quando você lida com desenvolvimento relacionado à interface do usuário, enquanto abaixo pode haver mais padrões - fábrica, singleton, fachada e etc. A maioria dos grandes projetos consiste em várias camadas que lidam com aspectos diferentes, mas a interface do usuário pode não ser uma obrigação para alguns casos. Você pode ver muito o MVC - isso ocorre porque muitos projetos têm elementos de interface do usuário.

portanto, enquanto fala sobre as desvantagens do MVC, isso realmente depende dos projetos que você está realizando - ele possui interface do usuário? requer grande escalabilidade / extensibilidade? ele tem muitas interações entre a interface do usuário e o sistema atrás? por exemplo, uma página da Web simples de informações não requer MVC, a menos que você planeje estendê-la para uma ótima página interativa no futuro.

portanto, para avaliar o MVC (ou mais geral - um padrão de design), forneça um contexto e pense sobre complexidade, escalabilidade, capacidade de teste, manutenção, restrição de tempo etc. etc.

Rex
fonte