it-swarm-es.com

¿MVC es solo el SEO de la programación PHP?

Hay alrededor de un trillón de "frameworks PHP". Y la mayoría de ellos se facturan a sí mismos como siguiendo el patrón MVC. Si bien es bienvenido superar el estilo de codificación de osCommerce (lógica de procesamiento fuertemente entremezclada con SQL y HTML), ciertamente existen enfoques más simples y fáciles de seguir para obtener un diseño de aplicación sostenible.

El concepto MVC original estaba dirigido a aplicaciones GUI. Y para Gtk/Python parece factible seguirlo en consecuencia. Pero PHP las aplicaciones web no operan en vistas en vivo (elementos GUI) y un tiempo de ejecución del controlador persistente. Es ciertamente un nombre inapropiado si solo describe el código usado + agrupación de directorios o nombres de clases.

"MVC" parece ser usado como una palabra de moda para PHP frameworks. Y de hecho he visto uno o dos PHP frameworks maduros lo admiten, pero redefiniendo el frase de todos modos para que coincida con interna.
Entonces, ¿es generalmente aceite de serpiente? ¿Por qué no se usa una mejor terminología y no se propaga un concepto más sensato para mantener PHP?

n razonamiento elaborado

Por qué sospecho que las implementaciones de PHP no siguen el patrón MVC real:

Modelos: en teoría, los modelos deberían ser gruesos y contener lógica empresarial, y los controladores deberían ser manejadores delgados (entrada-> salida). En realidad, los marcos PHP abogan superficial Modelos. CI y Symfony, por ejemplo, igualan Model == ORM. Incluso la entrada HTTP es manejada por el controlador, no se trata como modelo.

Vistas: soluciones con AJAX descontado, no puede haber Vistas en las páginas web. PHP frameworks todavía bombean páginas. La interfaz aún sigue efectivamente el modelo HTTP ordinario, no hay ninguna ventaja sobre las aplicaciones que no son MVC. (Y por último, ninguno de los marcos php generalizados puede generar resultados en vistas GUI en lugar de HTML. He visto un PHP biblioteca que puede operar Gtk/Console/Web, pero los frameworks no.)

Controlador: No estoy seguro. Es probable que los controladores no necesiten ser de larga duración y estar permanentemente activos en el modelo MVC. En PHP framework context, sin embargo, son en su mayoría manejadores de solicitudes. No es realmente algo sobre lo que discutir, pero se siente un poco de moda.

¿Habría mejores descriptores? He visto acrónimos como PMVC o HMVC. Aunque las descripciones se vuelven más ambiguas allí, ¿tal vez estas describirían los marcos web actuales de forma menos cursi?

9
mario

Creo que estás viendo esto de una manera completamente incorrecta. Una aplicación GUI y una página web son mundos aparte, por lo que la misma definición exacta de MVC nunca funcionará para ambos. MVC se trata más de lo ideal: separar ciertas partes de la aplicación, como la visualización y la lógica.

En PHP (o la web en general), a Ver es la página web en sí: la salida HTML. No está "en vivo" según tu definición, pero simplemente haga clic en los enlaces para volver al controlador (es decir, otra solicitud de página).

El controlador y modelo es donde las cosas difieren, como usted explicó. En PHP el modelo tiende a ser la capa de datos, interactuando con la base de datos y así sucesivamente. Pero todavía está modelando la situación, y el controlador aún controla el flujo de la aplicación, aunque solo sea una vez por página carga.

Entonces, el nombre "Modelo-Vista-Controlador" es perfectamente lógico, aunque una implementación diferente en aplicaciones GUI frente a aplicaciones web.

12
DisgruntledGoat

Como no conozco los marcos de trabajo PHP, esto se ve desde una vista de lenguaje de bajo nivel.

Modelos:

en teoría, los modelos deberían ser gruesos y contener lógica empresarial

Eso está completamente por hacer, no veo qué tiene que ver PHP con esto ...

Los modelos son clases de datos en PHP que probablemente podrían comunicarse con la base de datos,
entonces también podría enviar el mismo modelo o un modelo parcial en formato JSON al cliente.

No diría lógica de negocios, es más como lógica de datos (validación, interacción de bases de datos, importación/exportación, ...).

y los controladores deben ser controladores delgados (entrada-> salida)

Sus clases de controlador interactúan con las clases de modelo, de hecho son delgadas.

Según el resultado, haga algunas cosas con los modelos ... y devuelva un ModelView al cliente ...

En realidad, los frameworks PHP abogan por modelos poco profundos. CI y Symfony, por ejemplo, equiparan Model == ORM. Incluso la entrada HTTP es manejada por el controlador, no se trata como modelo.

Realmente no estoy al tanto de esos PHP frameworks ...

Pero la entrada HTTP debe manejarse antes de que llegue al controlador,
puede crear fácilmente una clase que convierta los datos GET y POST en buenos parámetros y enrutamiento.

Esto es exactamente lo que sucede en ASP.NET MVC 2 y no tiene nada de malo,
No sé cómo sucedería esto con PHP pero supongo que estaría muy relacionado.

Incluso podría convertir fácilmente los datos GET y POST en un modelo, el modelo tal vez podría contener lógica de constructor para eso. O se podrían agregar algunas clases separadas para ese propósito).


Vistas:

soluciones alternativas con AJAX con descuento, no puede haber Vistas en las páginas web. PHP los frameworks aún bombean páginas.

No veo por qué no podría, la única diferencia es el protocolo y PHP puede devolver JSON, etc ...

Una página es su vista y puede solicitarla y actualizarla a través de AJAX + JSON.
Una vez más, no estoy realmente al tanto de esos marcos PHP pero en ASP.NET MVC 2 funciona de esa manera.

La interfaz aún sigue efectivamente el modelo HTTP ordinario, no hay ninguna ventaja sobre las aplicaciones que no son MVC. (Y, por último, ninguno de los marcos php generalizados puede generar resultados en vistas GUI en lugar de HTML. He visto una biblioteca PHP que puede operar Gtk/Console/Web, pero los marcos no ' t.)

La única ventaja que obtiene (y es lo mismo con las aplicaciones normales) es la separación en Modelo (Datos) + Vista (GUI) + Controlador (Lógica). De manera similar, no verá un marco C++ que pueda generar resultados en HTML o JSON en lugar de Vistas GUI.


Controlador:

No estoy seguro Es probable que los controladores no necesiten ser de larga duración y estar permanentemente activos en el modelo MVC. En PHP framework context, sin embargo, son en su mayoría manejadores de solicitudes. No es realmente algo sobre lo que discutir, pero se siente un poco de moda.

MVC es una arquitectura/patrón de software, donde se ejecuta el controlador y durante cuánto tiempo no funciona.

3
Tamara Wijsman

Pero PHP las aplicaciones web no operan en vistas en vivo (elementos GUI) y un tiempo de ejecución de controlador persistente.

¡No, seguro que sí!

Piense en AJAX aplicaciones, luego la vista le pregunta algo al controlador y obtiene una vista parcial,
esta vista o datos se completan en algún lugar de la página y, por lo tanto, se actualizan en vivo.

El controlador también es persistente porque puede usar cookies/sesiones.

"MVC" parece usarse como una palabra de moda para PHP frameworks.

MVC es una arquitectura de software, algunos marcos pueden usarlo como un zumbido, pero otros lo hacen correctamente ...
Ver na lista de algunos marcos en Wikipedia .

¿MVC es solo el SEO de la programación php?

MVC y SEO son dos cosas distintas, pero sí ... MVC se está volviendo más popular.

1
Tamara Wijsman