model view controller - explained - ¿Cómo encaja Gang of Four Design Patterns en el paradigma MVC?
pattern design mvc (4)
El MVC en el libro de GoF es para el escritorio, usa el patrón de observador para actualizar las vistas. El ejemplo de comando en el libro de GoF es para un editor.
Hay otros sabores de MVC donde el uso de otros patrones de diseño puede no ser obvio:
¿Cuál es la diferencia entre MVC y MVVM?
Presentación de control de abstracción.
El libro de GoF dice:
...
Tomado a valor nominal, este ejemplo refleja un diseño que desacopla las vistas de los modelos. Pero el diseño es aplicable a un problema más general: el desacoplamiento de los objetos para que los cambios en uno puedan afectar a cualquier número de otros sin que el objeto cambiado sepa los detalles de los otros. Este diseño más general se describe en el patrón de diseño Observer (página 293).
Otra característica de MVC es que las vistas se pueden anidar. Por ejemplo, un panel de control de botones podría implementarse como una vista compleja que contiene vistas de botones anidadas. La interfaz de usuario para un inspector de objetos puede consistir en vistas anidadas que pueden reutilizarse en un depurador. MVC admite vistas anidadas con la clase CompositeView, una subclase de vista. Los objetos CompositeView actúan como los objetos Ver; se puede usar una vista compuesta donde se puede usar una vista, pero también contiene y administra vistas anidadas.
Nuevamente, podríamos pensar en esto como un diseño que nos permite tratar una vista compuesta al igual que tratamos uno de sus componentes. Pero el diseño es aplicable a un problema más general, que ocurre cuando queremos agrupar objetos y tratar al grupo como un objeto individual. Este diseño más general se describe en el patrón de diseño Compuesto (163). Le permite crear una jerarquía de clases en la que algunas subclases definen objetos primitivos (p. Ej., Button) y otras clases definen objetos compuestos (CompositeView) que ensamblan los primitivos en objetos más complejos.
MVC también le permite cambiar la forma en que una vista responde a las entradas del usuario sin cambiar su presentación visual. Es posible que desee cambiar la forma en que responde al teclado, por ejemplo, o hacer que use un menú emergente en lugar de teclas de comando. MVC encapsula el mecanismo de respuesta en un objeto Controller. Existe una jerarquía de clases de controladores, lo que facilita la creación de un nuevo controlador como una variación de uno existente.
Una vista utiliza una instancia de una subclase de controlador para implementar una estrategia de respuesta particular; para implementar una estrategia diferente, simplemente reemplace la instancia con un tipo diferente de controlador. Incluso es posible cambiar el controlador de una vista en tiempo de ejecución para permitir que la vista cambie la forma en que responde a la entrada del usuario. Por ejemplo, una vista se puede deshabilitar para que no acepte entradas simplemente dándole un controlador que ignora los eventos de entrada.
La relación Vista-Controlador es un ejemplo del patrón de diseño de Estrategia (315). Una estrategia es un objeto que representa un algoritmo. Es útil cuando desea reemplazar el algoritmo de forma estática o dinámica, cuando tiene muchas variantes del algoritmo, o cuando el algoritmo tiene estructuras de datos complejas que desea encapsular.
MVC usa otros patrones de diseño, como Método de fábrica (107) para especificar la clase de controlador predeterminada para una vista y Decorador (175) para agregar el desplazamiento a una vista. Pero las relaciones principales en MVC están dadas por los patrones de diseño Observer, Composite y Strategy.
...
He reflexionado sobre los patrones de diseño desde hace algún tiempo y estoy empezando a ver cómo puedo comenzar a incorporar algunos de estos más deliberadamente en mi trabajo de desarrollo. Sin embargo, todavía estoy confundido acerca de su tratamiento de MVC al principio del libro y cómo se relaciona con el resto del libro.
La mayoría de los marcos con los que he trabajado (Spring, Yii, ASP.NET e incluso Objective-C Cocoa (UIKit)) se adaptan al paradigma MVC. Obtengo MVC porque para mí es una forma útil de clasificar objetos y cómo deben enviarse mensajes o interactuar entre ellos. Además, estos marcos te obligan a hacerlo incluso si no te propones pensar de la forma MVC.
También siento que entiendo la premisa de los patrones de diseño : a ellos realmente no les gustan las subclases, les encantan las interfaces abstractas y se esfuerzan por un acoplamiento flexible. No puedo decir que entiendo completamente todos los patrones todavía o cómo son útiles, pero me estoy dando cuenta de ello.
Mi pregunta es la siguiente: ¿cuál es la interacción entre MVC y los patrones de diseño? ¿A qué se referían en el primer capítulo del libro con el ejemplo de aplicación MVC? ¿Algunos patrones de diseño simplemente no son relevantes en el paradigma MVC? Me pregunto, por ejemplo, cómo se supone que el patrón de Comando se ajusta a MVC. Parece increíblemente útil, pero ¿creamos un CommandModel y un CommandController para enviar a otros controladores? ¿Simplemente creamos un objeto de Command según lo prescrito en el libro? Básicamente, me pregunto si las ideas de MVC y los patrones de diseño son totalmente inconexas y simplemente no entiendo, o si hay algunos patrones que no encajan en el molde.
MVC es un patrón arquitectónico . Se adapta perfectamente a otros patrones de diseño como Command Pattern. Pero no aplica los patrones solo porque existen y están escritos en un libro autorizado. Usted aplica patrones cuando tiene un problema de programación / diseño y hay una manera de resolver ese problema que fue descubierta por otra persona y que fue anotada. La forma de resolver un problema es un patrón. Por ejemplo, tiene una aplicación que guarda los datos en la base de datos. Los datos a guardar son bastante complejos: algunos registros deben insertarse, algunos registros deben actualizarse y otros deben eliminarse. La secuencia de pasos es importante porque los registros que se insertarán en una tabla dependen de los registros que se insertarán en otra tabla. Por lo tanto, una transacción de base de datos debe ser utilizada. Una de las posibles formas de implementar la transacción es usar el patrón de comando. La forma de hacerlo está muy bien explicada en el libro " Aplicación de UML y patrones " de Larman (capítulo "Diseño de un marco de persistencia con patrones", sección "Diseño de una transacción con el patrón de comando": desplácese hasta la página 556). PersistentObject es una clase de modelo abstracto allí. Todas las demás clases de modelos lo extienden. En ese ejemplo, MVC se implementa en las capas UI, Aplicación y Dominio, pero Comando se implementa en la capa Persistencia. Estos patrones ayudan a resolver diferentes problemas y se apoyan mutuamente en ese ejemplo.
MVC es un patrón. Pero solo cubre un pequeño aspecto de una aplicación web. Otro patrón común que se usa con MVC es el Repositorio. Estos son más patrones arquitectónicos ... su alcance tiene un mayor impacto en el proyecto en general.
Los patrones de GOF se presentarán de pequeñas maneras por todas partes. Pueden ayudar a construir la infraestructura MVC dependiendo de las opciones de diseño. Por ejemplo, la estrategia se usa mucho, por lo que puede conectar diferentes formas de hacer cosas como "autenticación", etc.
No tiene que usar los patrones como son, ni siquiera tienen que ser exactamente la misma estructura de código. Es más el principio / objetivo de diseño del patrón que emplea en el diseño.
Mi opinión personal es que MVC es una versión simplificada del patrón de observador que es una versión simplificada del patrón de mediador.
MVC : Un modelo, una vista, el controlador controla la comunicación entre ellos.
Patrón de observador : un modelo, múltiples vistas (observadores / suscriptores), y el editor gestiona la comunicación
Patrón del mediador : varios modelos diferentes, varias vistas y el mediador gestiona las comunicaciones entre ellos.