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

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.

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.

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:

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.

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.

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.

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.