For information on exhibition and sponsorship opportunities at RailsConf, contact Yvonne Romaine at email@example.com.
Download the RailsConf Sponsor/Exhibitor Prospectus
View a complete list of RailsConf contacts.
It’s surprising that DCI (Data-Context-Interaction) hasn’t received more industry-wide attention. It has an impressive pedigree – it was created by James Coplien and Trygve Reenskaug, the inventor of MVC – and it addresses common software issues.
However, the DCI approach, which has been described as object-oriented instead of class-oriented, is not conducive to implementation in languages like Java and C#, which could explain the lack of attention. With the flexibility of Ruby, implementing DCI is fairly straightforward. Rails developers should be leading the way in advancing software architecture with the adoption of DCI.
This talk will be an introduction to DCI, and will describe how DCI goes beyond MVC in helping divide application responsibilities and improve maintainability. Specifically, DCI addresses common issues such as: bloated domain objects with multiple personality disorder; grey areas between M, V, and C; blending of code with varying rates of change; and test / database decoupling – issues faced by most significant Rails applications.
Here’s a relatively brief summary of DCI:
Although the concept of roles is not new in software development, DCI promotes roles to a critical level of importance. Domain objects are not reduced in importance, but are set free from all of the baggage typically dumped on them to support all of the roles they are expected to fill. The objects are distilled to their basic essence, still encapsulating their data, but only providing the methods essential to what the object “is”, not everything it “does”.
Roles are the home for all of the things an object does. Obviously each object can fill many roles, with each role cleanly separating what would otherwise be mashed into one of the many personalities of the object. In addition, the role / object separation opens up the possibility of having roles that support many types of objects – as long as the underlying object supports the interface required by the role, everything’s good.
In DCI, roles are not standalone objects; they don’t even have to be implemented as classes. A role is a set of methods to be dynamically added to an object. In Ruby, roles can be implemented as modules, simply extending the appropriate domain objects. (It’s a bit more complicated in crustier languages ;-)
The linking of roles to domain objects is the responsibility of the Contexts. Each user / system interaction scenario is represented by a context, typically initiated by a controller. The context not only assembles the roles and objects, but also orchestrates any high-level interaction that does not cleanly fit within the object roles nor the controller (for example, a sequence of steps specific to the implementation of a story). Contexts can be nested and reused, but should be stacked, so that only one is active at any time.
For more details, see: http://www.artima.com/articles/dci_vision.html, Coplien’s “Lean Architecture” book, and other related papers by Reenskaug and Coplien.
Mike Dietz is a Senior Consultant with ThoughtWorks. He has written applications in Smalltalk and Ruby/Rails, and done time as a Java developer in between. Trying to be a good programmer…
“Any fool can write code that a computer can understand. Good programmers write code that humans can understand.” ~Martin Fowler
Comments on this page are now closed.