model view controller - tier - ¿Cuáles son las principales ventajas del patrón MVC sobre el patrón de 3 capas pasado de moda?
tier software architecture (4)
Estoy pensando en usar un patrón MVC en mi nuevo proyecto y puedo ver claramente la principal ventaja de poder poner la capa de datos (el modelo) un poco más cerca de la capa de presentación (la vista), lo que permitirá un pequeño aumento en la velocidad de la aplicación. Pero aparte del punto de vista del desempeño, ¿hay otras ventajas de MVC sobre el patrón de tipo de capas de visualización de datos lógicos?
EDITAR: para aquellos que estén interesados acabo de subir un código PHP de muestra que creé para probar el uso de MVC. Intencionalmente omití todas las comprobaciones de seguridad para hacer que el código sea un poco más fácil de leer. Por favor, no lo critique demasiado, porque sé que podría ser mucho más refinado y avanzado, pero sin embargo, ¡funciona! Agradeceré las preguntas y sugerencias: aquí está el enlace: http://www.sourcecodester.com/sites/default/files/download/techexpert/test_mvc.zip
Donde 3 capas separan la presentación del negocio y el acceso a los datos, MVC es un patrón de capa de presentación que separa aún más el Modelo (datos) de la Vista (pantalla) y el Controlador (entrada).
No se puede elegir MVC en 3 niveles / 3 capas. Úselos a ambos.
Junto a
- reutilización del código,
- separación de preocupaciones,
- menos acoplamiento entre las capas,
ya mencionado por @bakoyaro y @arjan
Creo que MVC es mejor que 3 niveles cuando se combina con el patrón "convención sobre configuración" . (es decir, "ruby on rails" o Microsofts "MVC for asp.net").
En mi opinión, esta combinación conduce a un mejor y más fácil mantenimiento del código .
En primer lugar, hace que aprender mvc-framework sea un poco más difícil ya que tiene que aprender las convenciones (los controladores van a la carpeta de controladores y deben llamarse xxxxxcontroller)
Pero después de que haya aprendido las convenciones, es más fácil mantener su propio código y el código externo.
La separación de las preocupaciones que se cita como una ventaja de MVC es en realidad también un avance de un sistema de 3 capas / 3 niveles. También allí, la lógica comercial es independiente y se puede usar desde diferentes niveles de presentación.
Una diferencia principal es que en MVC clásico, el modelo puede tener una referencia de regreso a la vista. Esto significa que cuando los datos se actualizan, el modelo puede volver a enviar estos datos a posibles vistas múltiples. El mejor ejemplo es una aplicación de escritorio donde los datos se visualizan de múltiples maneras. Esto puede ser tan simple como una tabla y un gráfico. Un cambio en la tabla (que es un cambio en una vista) primero se empuja a través del controlador hacia el modelo, que luego lo empuja de vuelta al gráfico (la otra vista). El gráfico luego se actualiza solo.
Dado que el desarrollo de escritorio está en declive, muchos programadores solo han entrado en contacto con MVC en alguna variante de la Web, por ejemplo, a través de JSF en Java EE.
En esos casos, el modelo casi nunca tiene una referencia a la vista. Esto se debe a que la web se basa principalmente en la solicitud / respuesta y, una vez que se ha atendido una solicitud, el servidor no puede enviar información adicional. Es decir, una actualización realizada desde el modelo al cliente no tendría sentido. Con el ajax / cometa invertido, esto está cambiando, pero muchos frameworks MVC basados en la web todavía no utilizan completamente esto.
Por lo tanto, en el caso de MVC basado en web, el típico "triángulo" entre M, V y C es menor allí y esa variante de MVC está realmente más cerca de un modelo de n niveles que ''verdadera'' es MVC.
También tenga en cuenta que algunos frameworks MVC web tienen una parte intermedia de fontanería entre M, V y C llamada bean de respaldo (Java / JSF) o código detrás (ASP.NET). En JSF, el controlador proporciona el controlador, y la vista a menudo no se vincula directamente al modelo, sino que utiliza este bean de respaldo como intermediario. El bean de respaldo es muy delgado y básicamente solo recupera los datos del modelo de una manera y traduce mensajes específicos del modelo (por ejemplo, excepciones) para ver mensajes específicos (por ejemplo, algún texto legible por humanos).
Olvídese de aumentar la velocidad de la aplicación moviéndose a MVC. He encontrado que el mayor beneficio es la facilidad de reutilización del código. Una vez que se muda a MVC, no hay dependencias en la presentación de sus datos ni en el almacenamiento de los datos reales.
Por ejemplo, podría escribir un servlet que sirviera las páginas .jsp como su capa de presentación un día, y al día siguiente escribir un servicio web como otra capa de presentación para su Modelo y Controlador existente. Me gusta si quieres o necesitas cambiar tu DBMS. Debido a que el acceso al Modelo está completamente separado de todo lo demás, solo necesita volver a escribir solo sus objetos de acceso a datos para devolver los datos de la manera que su Controlador pueda manejarlos.
Al separar las inquietudes en 3 piezas distintas, también facilita la verdadera prueba unitaria. Su capa de Presentación puede probarse sin el Modelo o Controlador, y viceversa.
En una nota al margen, a menudo he sentido que la abreviatura de MVC era inexacta. Cada vez que lo veo, lo veo como Ver-> Controlador-> Modelo . La capa de presentación nunca tendrá código DAO, y el modelo nunca tendrá lógica de presentación. El controlador se ve obligado a actuar como intermediario.