oop - ¿Es Modelo-Vista-Controlador pobre diseño orientado a objetos?
model-view-controller design-patterns (4)
Nada en MVC dice que el Model debería ser estúpido (modelo anémico). Creo que es completamente apropiado tener clases de Model enriquecidas, que eliminan la necesidad de "gerentes".
Dicho esto, actualmente es una práctica popular utilizar ViewModel s para pasar datos a una View . ViewModel es básicamente una proyección de su Model diseñada específicamente para una View particular. Se puede considerar como el Model desde la perspectiva de la vista, una fachada para un Model rico; así que, por supuesto, hay mucho más para un Model que solo ViewModel .
Las arquitecturas OOD (Object-Oriented-Design) y MVC (Model-View-Controller) se han convertido en elementos básicos del diseño de software moderno. Sin embargo, recientemente he tenido una discusión interesante sobre cómo las arquitecturas MVC utilizan (y posiblemente incluso violan ) los principios OOD. En realidad, esta posibilidad es bastante intrigante, ya que tanto OOD como MVC tienen la intención de lograr muchos de los mismos objetivos: separación de preocupaciones y reutilización del software. Pero la pregunta que planteo: ¿Están estas dos estrategias de diseño en conflicto directo entre sí? Como he usado ambos, en la práctica, estoy empezando a pensar: posiblemente sí.
Lo digo porque: al imponer una estricta separación entre los modelos, las vistas y los controladores a menudo resulta en arquitecturas donde los modelos se implementan como contenedores estúpidos que solo pueden manipularse a través de controladores externos. Sostengo que esto contradice directamente uno de los principios fundamentales del diseño orientado a objetos: cuando los objetos contienen operaciones que realizan operaciones necesarias y las encapsulan según sea necesario. Por ejemplo, en una arquitectura orientada a objetos pura, una clase de File hipotética contendría métodos como open() y save() . MVC sugiere que tengamos dos clases File y FileManager (de modo que esta última contenga los métodos open() y save() ). Para mí: el diseño de MVC es bastante desordenado. Si uno necesita crear un tipo de File más especializado (por ejemplo, para manejar archivos que se transmiten a través de una red en open() o save() ), solo se necesita crear una subclase de File con una clase llamada (digamos): StreamedFile . Con MVC, tendría que crear otra clase de administrador o complicar el diseño de la clase de administrador original.
De esto, se deduce que en un sistema más complejo, MVC podría tener efectos desastrosos tanto en la separación de preocupaciones como en la reutilización del código. ¿O no? Tal vez los patrones MVC podrían implementarse sin romper los principios OOD? ¿O es MVC un enfoque inherentemente defectuoso que dificulta la implementación de sistemas de software con componentes débilmente acoplados?
No llamaría a MVC una arquitectura que tiene el mismo dolor que OOD. MVC es solo un patrón OOD que se puede aplicar en ciertos diseños. Por lo tanto, simple no compite con OOD y es solo una de sus herramientas para crear un diseño de OOD bueno o malo. Al igual que un martillo no compite con una buena artesanía en madera, el martillo, como MVC, es solo una herramienta en la caja de herramientas del artesano.
Tampoco es patrón lo que facilita el mal diseño. Debido a que un buen diseño de OOD tendrá una buena separación de inquietudes, el patrón MVC puede proporcionar eso al separar las inquietudes de presentación (vista) de la lógica de la aplicación (controlador) y la lógica de dominio más fundamental (modelo). Como tal, es un buen patrón OO que a menudo se aplica en las interfaces de usuario. Pero hay otros patrones en competencia que también podrían considerarse al hacer un buen OOD.
Por el contrario, el uso saludable de MVC debería alentar a los controladores delgados y los modelos gruesos , de modo que los modelos (los objetos) estén donde ocurre la acción (que a su vez fomenta la encapsulación y otros buenos principios de la POO), y los controladores simplemente están ahí para señalar ciertas solicitudes En la dirección correcta a los objetos.
Tenemos dos formas de MVC, Pull MVC y Push MVC (también conocido como Component Based MVC y Legacy MVC).
Push MVC se enfoca en la separación de conceptos, cada conjunto de controlador de vista de modelo maneja algunos aspectos de la aplicación y puede ser diseñado y desarrollado por personas distintas. Cuando el sistema se está desarrollando rápidamente, funciona muy bien, y agregar funciones también es fácil. La reutilización del código en sistemas más grandes se vuelve terrible. Esencialmente solo los modelos son reutilizados.
Pull MVC, se centra en la reutilización del código mediante el uso de widgets (componentes de vista), de modo que muchas vistas comparten el mismo código y solo personalizan sus widgets. En cuanto a los controladores, las prácticas comunes de los controladores se resumen y se realizan.
Se trata de mezclar los MVC de extracción y empuje en función de la naturaleza y el ritmo del software.