Por que devo usar um padrão MVC?

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

I don't find it terribly useful to think of MVC as a pattern because it contains quite a few different ideas. Different people reading about MVC in different places take different ideas from it and describe these as 'MVC'. If this doesn't cause enough confusion you then get the effect of misunderstandings of MVC that develop through a system of Chinese whispers.

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

At the heart of MVC is what I call Separated Presentation. The idea behind Separated Presentation is to make a clear division between domain objects that model our perception of the real world, and presentation objects that are the GUI elements we see on the screen. Domain objects should be completely self contained and work without reference to the presentation, they should also be able to support multiple presentations, possibly simultaneously.

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 forma:

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

Controller - o que estou fazendo? Essa é a ação que está ocorrendo e o que, em um nível conceitual, precisa ser realizado. Por exemplo, quais etapas eu preciso percorrer para faturar um usuário? N.B. isso pode afetar qualquer quantidade de objetos, mas não sabe nada sobre como eles são persistidos no DB.

Visualizar - como renderizo o resultado?

O problema que eu sinto que você está vendo é que muitos aplicativos da web são uma interface CRUD (Create-Retrieve-Update-Delete) glorificada para um DB. isto é, 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 você executa não se aplicam diretamente a mudanças no modelo, 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 separe a lógica de suas visualizações. Se necessário, você deve usar uma arquitetura que utilize um controlador (como MVC) se houver uma lógica necessária que não se encaixe necessariamente em um modelo (como, digamos, um fragmento de URL de análise transversal de árvore).

Vindo do CI e do 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 manipular a lógica não específica do modelo parece diminuir. Assim, ao mover para o Django e depois para o Pyramid (nenhum dos quais segue completamente a arquitetura MVC), descobri que o controlador não era realmente um componente necessário para os aplicativos que eu estava construindo. Observe que ambas as estruturas têm recursos "controller'ish", como o URL Dispatching in Pyramid, mas é uma coisa de configuração, não uma coisa de tempo de execução (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 (quando trabalham em um ambiente de equipe).

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

Sim, a terminologia sobre isso é uma bagunça. É difícil falar sobre porque você nunca entende o que alguém significa pelos termos.

Por que um controlador separado, a razão pode depender de qual versão do controlador você está falando.

Você pode querer um controlador, porque quando você executa testes, a visão tem um monte de widgets que você não escreveu e provavelmente não quer testar. Sim, você separou a implementação da herança, então você pode usar um esboço ou simulado 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, você poderia testá-lo diretamente, e talvez não fosse necessário testar os widgets via script.

As outras versões são mais difíceis de mostrar para IMHO. Acho que é principalmente uma questão de separação de interesses - separar as preocupações da GUI visual da lógica que se aplica à GUI, mas não faz parte do modelo de negócios (coisas como traduzir atualizações do modelo em que os widgets devem estar visíveis). Mas, na prática, as duas classes provavelmente serão tão strongmente acopladas (mesmo se elas se comunicarem por meio de interfaces) que é difícil ficar muito aborrecido ao mesclá-las em apenas uma visão e ficar de olho em maneiras pelas quais a funcionalidade pode ser mais reutilizável. se eles fossem 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 simplesmente dizer que o MVC permite que você reutilize seu código com mais facilidade. Basicamente você programa seus modelos e seus controladores e pode usá-los indistintamente em um aplicativo da web, um aplicativo de mesa, um serviço, em qualquer lugar sem muito esforço.

Bem, a razão básica para usar 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. Assim, no caso, se o projeto passar de um módulo de uma organização para outro, é 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 forma combinada com um associado, discutiria primeiro e chegará a um modelo comumente acordado entre os dois. e seu associado). E, nesse caso, separa as responsabilidades atribuídas a você e ao seu associado, respectivamente, com uma margem distinta.

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

Eventualmente, tudo no servidor será apenas serviços ou "applets" que bombeiam dados para o front-end e, dependendo do tipo de cliente que você possui, esses dados serão consumidos e exibidos de forma 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 do que um controlador porque um controlador sempre precisa voltar ao modelo para alterar a exibição e isso é lento. No padrão MVVM, o ViewModel pode fornecer atualizações imediatas para a exibição. Além disso, o modelo MVVM promove os princípios de design RESTful IMHO.