Por que devo usar um padrão MVC?

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)

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 .

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.

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)

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.

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.

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.

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.