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


9

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?


Então, em conclusão: as estruturas PHP implementam um conceito semelhante ao MVC original. Eu acho que é melhor pregado aqui: stackoverflow.com/questions/1549857/simple-php-mvc-framework/…
mario

Fiquei surpreso ao ler que "a maioria das estruturas PHP usa Views como simplesmente páginas". Em todas as estruturas PHP que eu usei, um View pode ser qualquer coisa, é basicamente apenas um modelo HTML. Portanto, pode ser uma caixa de texto, uma barra lateral, uma barra de navegação, um bloco de texto estático ou mesmo um layout de página. Não consigo pensar em nenhuma estrutura que não permita a incorporação de Views no Views, permitindo que você faça praticamente qualquer coisa, desde que sua lógica / processamento de negócios seja feita no Controller de antemão.
Lotus Notes

O modelo (não plural) é uma camada . Não é um único arquivo ou classe. É uma coleção de objetos de domínio, mapeadores de dados e serviços. Leia isto .
21713 James

3
... SEO? "Motor de Otimização de Busca"?
Izkata

Respostas:


12

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.


Não tenho nenhuma discussão com o conceito abstrato de MVC. É minha objeção que as estruturas PHP sejam desonestas, na verdade, apenas implementando o Passive-MVC. Até o padrão "Model-View-Presenter" é uma descrição mais realista. Mas é claro que os termos devem ser dobrados quando você os aplica a um domínio diferente. A pergunta original; pode o termo dobrar torná-lo um chavão?
mario

3

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.


1

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.


11
Certamente, os elementos da interface do usuário do AJAX o aproximam, mas isso é objetivamente uma solução alternativa. E ainda parece distorcer a definição. (Btw, eu estou ciente de Cappucino.org e outros kits de ferramentas reais, mas foi refereing à bruta de frameworks PHP.)
mario

Não chamaria isso de solução alternativa, você também pode contar o Qt e outras estruturas como soluções alternativas também ... Existe apenas a sobrecarga de transferência de dados entre servidor e cliente, e com as atuais velocidades e latências de conexão, isso não é muito não mais. Não vejo como está dobrando a definição: o padrão isola a lógica do domínio (a lógica do aplicativo para o usuário) da entrada e apresentação (UI), permitindo o desenvolvimento, teste e manutenção independentes de cada um.
Tamara Wijsman

11
Eu vejo o que você quer dizer. Se você interpretar o PHP como servidor de aplicativos e o AJAX como mecanismo RPC entre a lógica e a interface do usuário, sim. Eu ainda chamaria isso de solução alternativa no HTTP. OTOH não tem certeza se é relevante para a denominação MVC. Acho que estou realmente contestando a implicação de que apenas "" "MVC" "" fornece as UIs da web responsivas e interativas que você descreve.
mario

-1

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.


+1 Mas é apenas uma vantagem de terminologia, ou existem estruturas PHP próximas a uma implementação Java. (E implicitamente, você está falando Java GUIs ou Web / Struts?)
mario

Eu não sei exatamente, mas estou usando o zend framework e acho que é o mesmo com outros frameworks MVC: é muito importante saber o que fazer em seu modelo, exibição e controlador e, portanto, a diferença entre o mundo da programação e o script de internets mundo está fechado. Talvez a era dos scripts internos tenha terminado, e eu adoraria ver isso. É muito buggy.
baklap
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.