Se implementa mal. Uno de los problemas descritos con MVC en el backend es que MVC originalmente estaba destinado a las interacciones GUI. Tendría sentido para MVC para JavaScript. El problema con PHP y otros lenguajes de back-end es que lo que se describe como interacción del usuario es realmente la respuesta a la acción del usuario. Entonces, el backend es realmente el modelo de una aplicación web MVC.
La idea de MVC en PHP ha crecido a partir de tomar el patrón de diseño MVC existente e intentar aplicarlo al backend dentro del contexto de separar las preocupaciones de todas las piezas necesarias para atender una solicitud.
Los primeros intentos terminaron con el Modelo siendo el acceso directo a la base de datos y los datos. La Vista son las plantillas que finalmente se sirvieron al usuario. El controlador era el enrutador y las acciones que se llamaban controladores y eran clases que contenían las acciones que se llamaban en función del enrutador.
- ¿Para qué se usa Django? ¿Puedo crear un juego?
- ¿Debo aprender programación competitiva o simplemente centrarme en el desarrollo web?
- ¿Estudiar desarrollo web en 2016 no es útil?
- ¿Cuál es la mejor manera de crear imágenes para WordPress?
- Cómo obtener una sola cuenta de alojamiento web para múltiples clientes
El patrón MVC ha comenzado a evolucionar hacia mejores implementaciones y posibles mejores patrones de diseño para procesos frontend y back end.
Para Laravel, la parte del enrutador del controlador acepta puntos finales que luego se evalúan y se llama a la acción asociada con esa ruta o punto final. La nomenclatura “Controlador” todavía se usa para agrupar acciones similares en una clase. Laravel en sí ha crecido desde preocuparse realmente por las solicitudes GET y POST hasta la mayoría de los verbos permitidos por HTTP. El Controlador dentro de Laravel está ahí para enrutar solicitudes y ejecutar los modelos y devolver la Vista después de que todo se haya procesado.
Al usar Laravel nuevamente, en realidad no sugiere cuáles son los modelos y se le permite usar Eloquent para acceder a los datos. Según tengo entendido, se suponía que el Modelo era más de la capa de servicio o la lógica empresarial que manejaba los datos.
No sé cómo MVVM (Model-View-ViewModel) o MVP (Model-View-Presenter) difieren de MVC. Aparte de eso, es más una forma de separar la lógica empresarial de la Vista.
El problema con MVC es que las implementaciones comunes de acciones requieren que la Vista y el Modelo se conozcan entre sí o que al menos lo suficiente del código en la acción Controlador sepa sobre la vista para tomar lo que devuelve el modelo para proporcionar lo que requiere el Ver. Esto viola los conceptos de OO, ya que si bien la Vista y el Modelo están separados y, por lo tanto, debería poder usar cualquier Modelo con cualquier Vista y cualquier Vista con cualquier Modelo, este no es el caso y una violación de la implementación adecuada de OO. Tiene una dependencia que no está definida y que el usuario debe conocer.
Creo que ViewModel está destinado a vincular la vista al modelo, de modo que los datos pasados a ViewModel se procesen y se devuelvan. Entonces, si bien tiene un sistema de Vista que podría ser JSON, XML, HTML, etc., también tiene ViewModel que maneja el paso de los datos a las diferentes vistas. Es más que ViewModel tiene un contrato y siempre que la plantilla cumpla con ese contrato, la Vista se devolverá correctamente.
Los matices de las diferentes implementaciones son lo más importante, ya que definirá cómo se supone que debe presentar la Vista y cómo pasar los datos a la Vista. MVP podría ser un mejor término para lo que hacen los frameworks PHP, ya que la mayoría de las acciones del controlador realmente solo sirven para pasar los datos del modelo a la Vista y más permiten lo que un Presentador serviría.
El enrutador existe en el controlador para ejecutar la acción correcta para manejar la solicitud y usar el modelo y la vista para responder.
El error común es que el Modelo es la capa de datos de MVC, pero eso no es cierto. Es más exacto decir que al Modelo no le debería importar de dónde provienen los datos que deben pasar a la Vista. Si los datos de los que está extrayendo son XML, JSON, DB, HTTP, etc., entonces el modelo no debe definir o importar dónde se extraen los datos. Solo debe preocuparse por su relación con los datos, mejor definidos por una interfaz y devolverlos a la Vista .
La vista en sí no necesita ser HTML o XML o incluso una plantilla. Es simplemente la representación final del Modelo y sus datos. Supongo que técnicamente, el Modelo no necesita datos ni siquiera necesita procesar nada. La vista es cualquiera que sea la respuesta en el contexto de PHP y MVC.
MVC en PHP es realmente complicado por los marcos que intentan implementar MVC o patrones modernos de lo que se aprendió del patrón MVC.
