Aplicación MVC. ¿Cómo encaja la arquitectura de varios niveles?

Question

Soy nuevo en el concepto de MVC y arquitectura web de niveles múltiples. Desarrollo una aplicación PHP y estoy usando uno de los marcos MVC disponibles. Mi pregunta es la siguiente:

Por lo que entiendo, MVC en sí mismo no se considera una arquitectura de varios niveles. Puedo entender cómo usar MVC solo es un paso adelante para adoptar un enfoque no estructurado, pero estaba contemplando cómo encajaría una simple arquitectura de 3 niveles. ¿Residiría MVC en la capa de presentación? ¿Cuáles son los méritos de agregar un enfoque escalonado? Por lo que consigo, solo con MVC no hay objetos de datos explícitos responsables de recuperar datos de la base de datos y esto generalmente se rellena en el modelo. Del mismo modo, la lógica de negocios, que en una arquitectura de 3 niveles residiría en una 'capa de negocios' (o como quieras llamarlo), se puede meter en el controlador.

¿Es mi comprensión algo correcto? Sé que hice muchas preguntas, pero me gustaría escucharlo discutir cómo incorporó una arquitectura de nivel N en su marco MVC (PHP o no), ya que supongo que los dos no son mutuamente excluyentes. ¡Gracias!

Answer 1

M) m es tu modelo. Esto generalmente vive en su capa de negocios o en la capa justo detrás de su capa de presentación. Sin embargo, a muchas personas no les gusta que la capa de presentación tenga ningún conocimiento de la capa de negocios, por lo que abstractan aún más al tener lo que se llama ViewModel. Estos con frecuencia son DTO (objetos de transferencia de datos) que se asignan libremente a su modelo de dominio. Para mí (.NET Guy) hay herramientas como AutOmapper para realizar la conversión del modelo de dominio para ver el modelo.

V) v es su punto de vista. La vista es su capa de presentación. Este es el código HTML o PHP real con el que el usuario toca e interactúa directamente. La vista debe ser lo más ligera posible (lo que significa que no hay lógica si es posible). Trate de mantener cualquier tipo de escenarios si/luego escriba escenarios fuera de la vista y manténgase solo para mostrar y recopilar datos. Presente un Modelo de View a sus diseñadores web para que no contaminen su Modelo de dominio.

C) C es su controlador. Esto es muy parecido a un coordinador. Toma datos de su vista y se asegura de que llegue a la función/método de back -end correctos para procesar esos datos. También coordina los datos desde el back-end en camino a la parte delantera.

Donde entran los conceptos de diseño de varios niveles están detrás de la capa de presentación (donde es donde MVC está principalmente). Cuando el controlador está tomando datos de la vista y los vuelve a pasar al final (si sigue el diseño DDD o impulsado por el dominio) pasaría los datos a un servicio de aplicación (una clase que coordina los asuntos de Back End). El servicio podría empujar aún más los datos a una capa de repositorio (que es una clase que habla con la base de datos, el sistema de archivos, los servicios web, etc., cualquier cosa de infraestructura). DDD es un gran tema, pero consistirá en el enfoque de nivel N y cómo funciona con MVC.

Mientras investiga este tema, eche un vistazo al COI (inversión de control), DI (inyección de dependencia), TDD (desarrollo impulsado por pruebas) y tantos patrones como sea posible (fachada, fábrica, etc.).

Answer 2

En general, la lógica comercial no debería estar en el controlador: terminaría con controladores masivos si siguió este patrón. El modelo básicamente alberga todas sus capas de no presentación ... acceso a datos, lógica comercial y objetos de entidad comercial. Su controlador prepara los datos comerciales para la vista.