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

Hay alrededor de un millón de "marcos PHP". Y la mayoría de ellos se consideran a sí mismos 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 que se pueda mantener.

El concepto MVC original estaba dirigido a aplicaciones GUI. Y para Gtk / Python parece factible seguirlo en consecuencia. Pero las aplicaciones web PHP no funcionan con vistas en vivo (elementos GUI) y un tiempo de ejecución del controlador persistente. Ciertamente es un nombre inapropiado si solo describe el grupo de código + directorio utilizado o el nombre de clase.

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

Algún razonamiento elaborativo

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

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

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

Controlador : no estoy seguro. Los controladores probablemente no necesiten ser de larga duración y persistentemente activos en el modelo MVC. Sin embargo, en el contexto del marco PHP, en su mayoría son manejadores de solicitudes. No es realmente algo sobre lo que debatir, 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 menos tontos?

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 tiene más que ver con el ideal: separar ciertas partes de la aplicación, como la pantalla y la lógica.

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

El controlador y el 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, etc. 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 carga de página.

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

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

Modelos:

en teoría, los modelos deberían ser gordos y contener lógica de negocios

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,
luego también podría enviar el mismo modelo o un modelo parcial en formato JSON al cliente.

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

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

Sus clases de Controlador interactúan con las clases de Modelo, de hecho son delgadas.

Según la salida, haga algunas cosas con los Modelos ... Y devuelva un ModelView al cliente ...

En realidad, los marcos de PHP abogan por modelos poco profundos. CI y Symfony, por ejemplo, equivalen a Modelo == ORM. Incluso la entrada HTTP es manejada por el controlador, no se trata como modelo.

No estoy realmente al tanto de esos marcos PHP ...

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 enrutamiento y parámetros.

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 estrechamente relacionado.

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

Puntos de vista:

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

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

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

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

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

Controlador:

No estoy seguro Los controladores probablemente no necesiten ser de larga duración y persistentemente activos en el modelo MVC. Sin embargo, en el contexto del marco PHP, en su mayoría son manejadores de solicitudes. No es realmente algo sobre lo que debatir, 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 importa.

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

¡No, seguro que sí!

Piense en las aplicaciones AJAX, 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 ser usado como una palabra de moda para frameworks PHP.

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

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

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

En mi opinión, usar MVC en php trae programadores a la web. Es más fácil pasar de Java a PHP, por ejemplo, cuando sabes cómo trabajar con MVC.