MVC é apenas o SEO da programação em PHP?

Há cerca de um zilhão de "estruturas PHP". E a maioria deles se considera seguindo o padrão MVC. Embora seja bem-vindo superar o estilo de codificação do osCommerce (lógica de processamento fortemente misturada com SQL e HTML), certamente existem abordagens mais simples e fáceis de seguir para obter um design de aplicativo sustentável.

O conceito original do MVC foi direcionado para aplicativos GUI. E para o Gtk / Python, parece viável segui-lo de acordo. Mas os aplicativos Web PHP não operam em Visualizações ao vivo (elementos da GUI) e em um tempo de execução persistente do Controller. Certamente é um nome impróprio se apenas descrever o código usado + o agrupamento de diretórios ou a nomeação de classes.

"MVC" parece ser usado como um chavão para estruturas PHP. E, na verdade, eu vi um ou dois frameworks PHP maduros admitirem, mas redefinindo a frase de qualquer maneira para corresponder a interna.
Então é geralmente óleo de cobra? Por que não é usada uma terminologia melhor e um conceito mais sensato para PHP sustentável propagado?

Algum raciocínio elaborativo

Por que suspeito que as implementações de PHP não seguem o padrão MVC real:

Modelos : em teoria, os modelos devem ser gordos e conter lógica de negócios, e os controladores devem ser manipuladores finos (entrada-> saída). Na realidade, as estruturas PHP defendem modelos rasos . CI e Symfony, por exemplo, igualam Model == ORM. Até a entrada HTTP é manipulada pelo controlador, não é tratada como modelo.

Exibições : soluções alternativas com desconto para o AJAX, não pode haver Exibições nas páginas da web. Estruturas PHP ainda distribuem páginas. A interface ainda segue efetivamente o modelo HTTP comum, não há vantagem sobre aplicativos não MVC. (E, por último, nenhuma das estruturas PHP amplamente difundidas pode gerar saída para GUI Views em vez de HTML. Vi uma biblioteca PHP que pode operar Gtk / Console / Web, mas as estruturas não.)

Controlador : Não tenho certeza. Os controladores provavelmente não precisam ser de longa duração e persistentemente ativos no modelo MVC. No contexto da estrutura PHP, eles são, na maioria das vezes, manipuladores de solicitações. Não é realmente algo para se argumentar, mas parece um pouco chato.

Haveria descritores melhores? Vi acrônimos como PMVC ou HMVC lançados. Embora as descrições fiquem mais ambíguas por lá, talvez elas descrevam os atuais frameworks da web menos obscuros?

Eu acho que você está olhando isso de maneira completamente errada. Um aplicativo da GUI e uma página da web estão separados por mundos; portanto, a mesma definição exata do MVC nunca funcionará para ambos. O MVC é mais sobre o ideal: separar certas partes do aplicativo, como exibição e lógica.

No PHP (ou na Web em geral), um View é a própria página da Web: a saída HTML. Não é "ativo" conforme sua definição, mas você simplesmente clica nos links para voltar ao controlador (ou seja, outra solicitação de página).

O controlador e o modelo são onde as coisas diferem, como você explicou. No PHP, o modelo tende a ser a camada de dados, interagindo com o banco de dados e assim por diante. Mas ainda está modelando a situação, e o controlador ainda controla o fluxo do aplicativo, mesmo que apenas uma vez por carregamento de página.

Portanto, o nome "Model-View-Controller" é perfeitamente lógico, embora com uma implementação diferente em aplicativos de interface gráfica do usuário e aplicativos da web.

Como não conheço as estruturas PHP, isso é visto de uma visão de linguagem de baixo nível.

Modelos:

em teoria, os modelos devem ser gordos e conter lógica de negócios

Isso está completamente pronto, não vejo o que o PHP tem a ver com isso ...

Modelos são classes de dados em PHP que provavelmente podem se comunicar com o banco de dados;
também é possível enviar o mesmo modelo ou um modelo parcial no formato JSON para o cliente.

Eu não diria lógica de negócios, é mais como lógica de dados (validação, interação com banco de dados, importação / exportação, ...).

e controladores devem ser manipuladores finos (entrada-> saída)

Suas classes Controller interagem com as classes Model, elas são realmente finas.

Com base na saída, faça algumas coisas com os modelos ... E retorne um ModelView ao cliente ...

Na realidade, as estruturas PHP defendem modelos rasos. CI e Symfony, por exemplo, igualam Model == ORM. Até a entrada HTTP é manipulada pelo controlador, não é tratada como modelo.

Eu realmente não estou ciente dessas estruturas PHP ...

Mas a entrada HTTP deve ser manipulada antes que ela chegue ao controlador;
você pode criar facilmente uma classe que transforma dados GET e POST em bons parâmetros e roteamento.

Isso é exatamente o que acontece no ASP.NET MVC 2 e não há nada de errado com isso,
não sei como isso aconteceria com o PHP, mas acho que estaria intimamente relacionado.

Você pode facilmente transformar os dados GET e POST em um modelo, o modelo pode conter lógica de construtor para isso. Ou algumas classes separadas podem ser adicionadas para esse fim.

Visualizações:

soluções alternativas com desconto para o AJAX, não pode haver visualizações nas páginas da web. Estruturas PHP ainda distribuem páginas.

Não vejo por que não pôde, a única diferença é o protocolo e o PHP pode retornar JSON, etc ...

Uma página é sua visão e pode solicitar e atualizar através do AJAX + JSON.
Novamente, não estou realmente ciente dessas estruturas PHP, mas no ASP.NET MVC 2 funciona dessa maneira.

A interface ainda segue efetivamente o modelo HTTP comum, não há vantagem sobre aplicativos não MVC. (E, por último, nenhuma das estruturas PHP amplamente difundidas pode gerar saída para exibições de GUI em vez de HTML. Eu vi uma biblioteca PHP que pode operar Gtk / Console / Web, mas as estruturas não.)

A única vantagem que você obtém (e é a mesma com os aplicativos normais) é a separação em Model (Data) + View (GUI) + Controller (Logic). Da mesma forma, você não verá uma estrutura C ++ que possa gerar de fato para HTML ou JSON, em vez de Visualizações da GUI.

Controlador:

Eu não tenho certeza. Os controladores provavelmente não precisam ser de longa duração e persistentemente ativos no modelo MVC. No contexto da estrutura PHP, eles são, na maioria das vezes, manipuladores de solicitações. Não é realmente algo para se argumentar, mas parece um pouco chato.

MVC é uma arquitetura / padrão de software, onde o Controller é executado e por quanto tempo não importa.

Mas os aplicativos Web PHP não operam em Visualizações ao vivo (elementos da GUI) e em um tempo de execução persistente do Controller.

Não, com certeza eles fazem!

Pense nos aplicativos AJAX, então a visualização solicita algo ao controlador e obtém uma visualização parcial de volta;
essa visualização ou dados são preenchidos em algum lugar da página e, portanto, atualizados ao vivo.

O controlador também é persistente porque você pode usar cookies / sessões.

"MVC" parece ser usado como um chavão para estruturas PHP.

MVC é uma arquitetura de software, algumas estruturas podem usá-lo como um burburinho, mas outras o fazem corretamente ...
Veja uma lista de algumas estruturas na Wikipedia .

MVC é apenas o SEO de programação php?

MVC e SEO são duas coisas à parte, mas sim ... MVC está ficando mais popular.

Na minha opinião, o uso do MVC no php traz programadores para a web. É mais fácil passar, por exemplo, de Java para PHP quando você sabe trabalhar com o MVC.