• Engine Yard
  • LivingSocial
  • VMware
  • Heroku
  • Rackspace Hosting
  • Blue Box Group
  • JetBrains
  • New Relic
  • Percona
  • Pivotal Labs
  • Rails Dog
  • WyeWorks
  • Chargify

Sponsorship Opportunities

For information on exhibition and sponsorship opportunities at RailsConf, contact Yvonne Romaine at yromaine@oreilly.com.

Download the RailsConf Sponsor/Exhibitor Prospectus

Contact Us

View a complete list of RailsConf contacts.

Beyond MVC -- DCI

Mike Dietz (ThoughtWorks)
General
Location: Ballroom III
Average rating: **...
(2.93, 46 ratings)

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.

Photo of Mike Dietz

Mike Dietz

ThoughtWorks

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.

Comments

Picture of Nicholas Henry
05/28/2011 3:43pm EDT

Thank you for making me aware of this design pattern, you achieved your goal! Perhaps code examples might have been helpful, but I was writing up some examples myself as you spoke. Fascinating. Will you be posting your slides? It would be helpful to refresh some of the key points you made. Thank you.

Picture of Stephen Walker
05/20/2011 2:32pm EDT

I agree with the code comments and having a really compelling use case to describe the benefits of DCI. Good topic, will look into it more.

Picture of Olek Poplavsky
05/20/2011 2:16pm EDT

Subject was good, and session definitely sparkled some interest in this area, will read more on it, but talk was a bit too dry and abstract for my taste.

05/20/2011 9:42am EDT

Agreed with the other commenters. Interesting topic, but I think if the code examples had come before the Q&A there might have been less repetition of content.

Picture of Mike Dietz
05/19/2011 8:29am EDT

Thank you very much for the feedback. I particularly appreciate your perspectives, since earlier feedback was that I should have spent more time on the concepts, rather than getting into the code. With an audience that size, I guess there is inevitably a diversity of experience levels and learning styles.

I hope you (and the rest of the audience) found the topic interesting enough, and the benefits compelling enough, to look into it further. That was my primary goal. I firmly believe that DCI would benefit the Rails community.

Picture of Paul Cook
05/18/2011 1:31pm EDT

I agree that it could have used more examples. Still a good intro to the idea and I’ll definitely be working on using it.

Chris Johnson
05/18/2011 12:18pm EDT

Definitely would have been more valuable to have illustrated with many more code examples. The talk was too abstract to be compelling in its current form.

05/18/2011 11:22am EDT

Hi, great topic, but I really wish you’d just started with the code. It would have been so much clearer (and exciting for the audience) if you’d illustrated all the concepts with code right from the beginning.