design patterns - pattern - DCI-Datos, contexto e interacción-¿Sucesor de MVC?
mvc design pattern (5)
¿Cuál es la mejor descripción de Datos, Contexto e Interacción (DCI) para presentarlo a una organización?
Fue creado por Trygve Reenskaug , el creador del MVC-pattern .
¿Es realmente el sucesor de MVC o simplemente otro patrón? ¿Y cuáles son sus ventajas y desventajas?
Creo que la mejor comprensión del sistema es una gran victoria para cualquier organización, pero también se podría argumentar que DCI es una mejora en MVC debido a los siguientes factores adicionales:
- La separación clara del comportamiento y los datos del sistema proporciona numerosos beneficios a las actividades de agregación de datos, que incluyen análisis en tiempo real más efectivos debido a la menor huella de los objetos de dominio.
- La reutilización de objeto de datos y objetos de comportamiento es mucho más fácil en divisiones funcionales cuando tienen su propio lugar para vivir en lugar de ser particulados como si se colocaran aleatoriamente en un subconjunto de los objetos de datos / comportamiento mezclados en un sistema.
- A medida que BDD se está convirtiendo en la metodología ágil de facto, la organización estará un paso adelante del resto de la industria en esta práctica y posiblemente un modelo a seguir para otras organizaciones afines.
La impresión que tengo es que no es un sucesor de MVC sino un complemento , por ejemplo, la figura 5 en el artículo artima de DCI tiene ambas. Creo que se supone que ayuda a diferenciar entre modelo y controlador, o quizás entre diferentes partes del controlador o diferentes partes del modelo.
La idea básica parece ser dividir la lógica para acciones particulares de nuestras clases de datos y moverla a rasgos / mixins / lo que sea, una acción por (usuario). Tendrás muchos pequeños trozos de código, en lugar de algunas piezas grandes. Además, parece que agregar nuevas mezclas se supone que es "mejor" que agregar funcionalidad a sus clases base. El código para acciones individuales probablemente (¿creo?) Estará más extendido, pero el código para diferentes acciones debería estar más claro y obviamente separado.
Me parece totalmente como el diseño basado en políticas de Andrei Alexandrescu en el diseño moderno de C ++; sin embargo, ese trabajo es de un nivel más bajo; DCI parece una arquitectura con partes de metodología (los casos de uso impulsan el diseño).
Trygve hace una presentación de DCI en https://vimeo.com/8235394
DCI ha sido creado para resolver un problema en la orientación de objetos: es muy difícil revisar el código OO.
El código para un caso de uso en OO está típicamente distribuido entre muchas clases. Para comprender cómo funciona el código, también debe conocer las relaciones entre los objetos en tiempo de ejecución. Estas relaciones no están establecidas en el código, sino que dependen de la situación.
Lo que DCI propone es que el código para un caso de uso dado se separe de las clases y se coloque en un artefacto diferente llamado contexto. Los objetos de diferentes clases pueden entrar en una relación en este contexto y participar en la interacción donde tienen roles diferentes.
¡El objetivo de DCI es hacer que el código OO sea más legible!
Así es como lo lanzaría.
Una buena pregunta y una pregunta frecuente. La respuesta corta es que es un paradigma basado en las ideas fundacionales de OO por Kay, Dahl y otros. Fue creado por Trygve Reenskaug como se nota con varios objetivos en mente. Una de ellas es el objetivo de hacer de las operaciones de IO ciudadanos de primera clase del programa. (No IO como en las operaciones de disco, sino toda la comunicación entre dos objetos diferentes). Otro objetivo importante de DCI es dividir lo que hace el sistema (funcionalidad / comportamiento) de lo que el sistema es (datos)