QU'est-ce que DCI et comment peut-il s'adapter aux Rails?
Un récent débat avec un collègue sur les différentes approches pour concevoir et coder les modèles dans une application Rails m'a amené à travers DCI dans le contexte de Rails .
Cependant, je n'arrive tout simplement pas à me concentrer sur tout ce concept, même après avoir passé cet exemple d'application.
Actuellement, j'ai tendance à aller juste plus ou moins "par le livre" lors de l'écriture d'une application Rails.
Donc il y a quelques choses que j'aimerais demander --
- QU'est-ce que DCI et quels sont ses avantages lorsqu'il est implémenté aux côtés de MVC sur l'ancien MVC (et vanilla ActiveRecord dans Rails) ?
- et comment peut-il être implémenté dans Rails (ou en d'autres termes, qu'est-ce que tous les modules )?
Modifier
Je voudrais encore élargir ma question dans le contexte de RoR - est-ce qu'un autre niveau d'abstraction entre les modèles et les contrôleurs dans Rails est recommandé? Quelle est l'étendue de il en applications à différentes échelles?
4 réponses
DCI est un paradigme et donc beaucoup plus qu'un moyen de concevoir une application. C'est une façon de penser à la modélisation ainsi qu'à la structuration du code. L'une des parties importantes de DCI est de garder ce qu'est le système (le modèle de domaine) et ce que le système fait (fonctionnalité) à part. DCI n'est pas une approche différente pour résoudre le même problème que MVC, donc votre première question ne peut pas vraiment être répondue. Vous pouvez utiliser MVC et DCI simultanément ce qui n'est pas un hasard puisque Trygve Renskaug est le père de les deux MVC et DCI. Il a récemment répondu à une question similaire sur le groupe google 'object-composition'.
L'exemple auquel vous avez lié viole certaines des idées de base telles que garder les rôles privés aux contextes et je ne pouvais pas non plus trouver un seul contexte, mais cela pourrait être dû au fait de ne passer que peu de temps à parcourir le code.
Je ne sais pas RoR moi-même donc je ne peux pas vous donner un exemple RoR mais si vous allez à fullOO vous trouverez des exemples écrits dans différentes langues, y compris à la fois Ruby et Marvin la première langue conçue pour DCI.
EDIT Il N'y a pas de réponse simple à la question" qu'est-ce que DCI " DCI est un paradigme, tout comme OOP est un paradigme. Ils ont tous deux les mêmes racines et répondre à la question ci-dessus est aussi compliqué que de répondre à "Qu'est-ce que la programmation orientée objet". Les choses sont encore plus compliquées par le fait que DCI est orienté objet et OOP dans tous les principaux langages OO est en fait orienté classe et pas orientée objet. DCI vise à produire du code où l'interaction entre objets au moment de l'exécution est visible dans le code au moment de la compilation et, en termes plus généraux, essaie de le rendre plus facile à raisonner sur le comportement d'exécution de la lecture du code. Le site que j'ai lié ci-dessus est consacré à expliquer ce qu'est DCI et répertorie également des exemples dans un certain nombre de langues. Ruby étant l'un d'entre eux
EDIT Il y a un livre sur ruby et DCI façon. L'auteur est assez actif sur object-composition et insightfull
Pour les personnes qui se demandent ce que signifie DCI..
DCI signifie Data Context Interaction
Au cœur de DCI se trouvent les outils cognitifs qu'il fournit au développeur. Je ne suis pas sûr si vous avez vu tous les grandsJames Coplien/Trygve Reenskaug conférences, mais je vais essayer de distiller l'essentiel de celui-ci pour toute personne nouvelle dans les concepts. Il s'agit de déplacer le comportement du système hors des objets de domaine en interaction des systèmes (entités de données, ou ce qu'est le système), et dans des objets de comportement (ce que fait le système) en tant que citoyens de première classe qui médient la collaboration entre les objets en leur injecter des fonctionnalités dans le contexte d'un cas d'utilisation juste à temps.
Pensez BDD. Nous codons le comportement non pas sur de nombreux objets comme des particules de fonctionnalité réparties sur nos objets de données qui sont fortement couplés à la couche de persistance, mais dans des objets cohésifs qui existent uniquement pour un cas d'utilisation( histoire), et qui injectent des capacités dans et coordonnent les interactions de ces objets de données stupides. Comme des couches pures d'une architecture physique, changeant lentement les données les objets ne sont pas chargés avec une implémentation de fonctionnalités en évolution rapide qu'ils transportent tout le temps. Plutôt, Ruby nous offre la possibilité de facilement injecter le comportement dans les objets lors de l'exécution si nécessaire seulement dans le contexte d'un cas d'utilisation.
Par exemple dans ROR, si vous avez une action de contrôleur impliquée dans un cas d'utilisation dans lequel il existe une matrice de probabilité d'événement où la plupart des entrées peuvent être déclenchées dans un faible pourcentage de requêtes, alors instancier un réseau de comportement gonflé-les objets lourds avec la connaissance d'exécuter chaque événement pour chaque cas d'utilisation possible des données sont inutiles. En outre, ne pas avoir à creuser 18 fichiers dans mon éditeur de texte pour comprendre comment fonctionne cette interaction par rapport à avoir toute la logique proprement abstraite aux modèles dans une interface fournie par l'objet context est également un avantage certain.
En ce qui concerne votre question sur "une autre" couche d'abstraction entre les contrôleurs et les modèles dans les rails, Je ne suis pas sûr de savoir quel autre un votre référence. Peu Importe, Oui. Par tous les moyens. Ce n'est rien. les modèles de conception et les principes de L'oncle Bobs SOLID sont à peu près les meilleures pratiques généralement acceptées dans la conception OO. Ces deux éléments encouragent fortement les abstractions faiblement couplées entre la Politique et la mise en œuvre. Ils aident tous deux à éviter les décharges cérébrales catostrophiques de l'empire romain démolissant l'ampleur, car ils fournissent un cadre commun que tout le monde comprend. DCI, pour moi, fournit le même type de cognitive cadre, mais pour rendre un système plus facile à comprendre et à traiter efficacement, et c'est le Saint Graal pour tout concepteur orienté objet.
Il y a un livre (en cours) sur l'utilisation de DCI dans Ruby / Rails: Clean Ruby . Je suggère fortement de vous mettre sur la liste de notification-j'ai lu des parties de ce livre et il semble vraiment Bon.
DCI est de plus en plus accepté dans le monde des Rails - il y a eu un certain nombre de billets de blog intéressants à ce sujet au cours des 3 derniers mois.