¿Qué es DCI y cómo puede caber con Rails?

Question

Un debate reciente con un compañero de trabajo sobre diferentes enfoques para diseñar y codificar los modelos en una aplicación de Rails me llevó a través de DCI in the context of Rails.

Sin embargo, parece que no puedo entender todo el concepto, incluso después de revisar this example application.

Actualmente, tiendo a ir más o menos "by the book" al escribir una aplicación de Rails.

Así que hay algunas cosas que me gustaría preguntar -

• ¿Cuál es la DCI y cuáles son sus ventajas cuando se utiliza junto con MVC sobre el viejo y simple MVC (y ActiveRecord vainilla en rieles)?
• Y cómo se puede implementar en Rails (o en otras palabras, ¿qué pasa con todos los módulos)?

Editar

me gustaría ampliar aún más mi pregunta en el contexto de RoR - Se recomienda otro nivel de abstracción entre los modelos y los controladores en los carriles? ¿Qué tan extendido está en aplicaciones de diferentes escalas?

Answer 1

DCI es un paradigma y, por lo tanto, mucho más que una forma de diseñar una aplicación. Es una forma de pensar sobre el modelado y el código de estructuración. Una de las partes importantes de DCI es mantener lo que el sistema es (el modelo de dominio) y lo que hace el sistema (funcionalidad). DCI no es un enfoque diferente para resolver el mismo problema que MVC, por lo que su primera pregunta no puede ser respondida. Puede usar MVC y DCI simultáneamente, lo cual no es una coincidencia ya que Trygve Renskaug es el padre de MVC y DCI. Recientemente ha respondido similar question a esto en el grupo de google 'composición de objetos'.

El ejemplo que ha vinculado viola algunas de las ideas básicas, como mantener los roles privados en los contextos, y tampoco pude encontrar un solo contexto, pero eso podría deberse a que pasé poco tiempo navegando por el código .

No sé RoR yo mismo así que no puedo darle un ejemplo de RoR, pero si va al fullOO encontrará ejemplos escritos en diferentes idiomas, incluyendo Ruby y Marvin, el primer idioma diseñado para DCI.

EDIT No hay una respuesta simple a la pregunta "¿Qué es DCI?" DCI es un paradigma, al igual que OOP es un paradigma. Ambos tienen las mismas raíces y responder a la pregunta anterior es tan complicado como responder "¿Qué es la programación orientada a objetos?". Las cosas son aún más complicadas por el hecho de que DCI está orientado a objetos y OOP en todos los principales lenguajes de OO está realmente orientado a clases y no orientado a objetos. DCI busca producir código donde la interacción entre los objetos en tiempo de ejecución sea visible en el código en tiempo de compilación y en términos más generales intente simplificar el razonamiento sobre el comportamiento del tiempo de ejecución al leer el código. El site al que me he vinculado anteriormente está dedicado a explicar de qué se trata DCI y también enumera ejemplos en varios idiomas. Ruby siendo uno de ellos

EDIT Hay un book en ruby ​​y DCI en su camino.El autor es bastante activo en composición de objetos y perspicaz

Answer 2

Hay un libro (actualmente en curso) sobre el uso de DCI en Ruby/Rails: Clean Ruby. Le sugiero que se ponga en la lista de notificaciones. He leído partes de este libro y parece realmente bueno.

DCI está ganando aceptación en el mundo de Rails: ha habido una cantidad de interesantes publicaciones en el blog al respecto durante los últimos 3 meses más o menos.

Answer 3

En el corazón de DCI están las herramientas cognitivas que proporciona el desarrollador. No estoy seguro de si has visto todas las excelentes lecturas de James Coplien/Trygve Reenskaug, pero trataré de extraer lo esencial para cualquier persona nueva en los conceptos. Se trata de mover el comportamiento del sistema fuera de los objetos de dominio interactivos del sistema (entidades de datos, o lo que es el sistema) y en objetos de comportamiento (lo que hace el sistema) como ciudadanos de primera clase que median la colaboración entre objetos inyectándoles funcionalidad en el contexto de un caso de uso just-in-time.

Think BDD. Codificamos el comportamiento no a través de muchos objetos como partículas de funcionalidad distribuidas por todos nuestros objetos de datos que están altamente acoplados a la capa de persistencia, pero dentro de objetos cohesivos que existen únicamente para un caso de uso (historia) y que inyectan capacidades en y coordinan las interacciones de estos objetos de datos tontos. Al igual que las capas transparentes de una arquitectura física, los objetos de datos que cambian lentamente no se cargan con una implementación de funciones que cambia rápidamente y que se transmiten todo el tiempo. Por el contrario, Ruby nos proporciona la capacidad de insertar fácilmente el comportamiento en los objetos en tiempo de ejecución cuando/si es necesario solo en el contexto de un caso de uso. Como ejemplo en ROR, si tiene una acción de controlador involucrada en un caso de uso en el que hay una matriz de probabilidad de evento donde la mayoría de las entradas pueden desencadenarse solo en un pequeño porcentaje de solicitudes, entonces crear una red de comportamiento inflado -objetos pesados ​​con el conocimiento para ejecutar cada evento para cada uso posible, el caso de los datos es innecesario. Además, no tener que excavar a través de 18 archivos en mi editor de texto para comprender cómo funciona esa interacción versus tener toda la lógica abstraída limpiamente en patrones en una interfaz proporcionada por el objeto de contexto es un plus definitivo también.

En cuanto a su pregunta sobre "otra" capa de abstracción entre los controladores y los modelos en los rieles, no estoy seguro de a qué otro se refiere. En cualquier caso, sí. Por todos los medios. No hay problema. Design patterns y los principios de SOLID de Uncle Bobs son generalmente buenas prácticas generalmente aceptadas en el diseño OO. Ambas fomentan fuertemente las abstracciones débilmente acopladas entre la política y la implementación. Ambas ayudan a evitar que los depósitos de sangre catostrófica del imperio romano demuelen la magnitud, porque proporcionan un marco común que todos entienden. DCI, para mí, proporciona el mismo tipo de marco cognitivo, pero para hacer que un sistema sea más fácil de comprender y tratar con eficacia, y este es el santo grial para cualquier diseñador orientado a objetos.

Answer 4

Para las personas que se preguntan cuál es DCI significa ..

DCI significa Data Context Interaction