Question

What is the best description of Data, Context and Interaction (DCI) to pitch it to an organization?

It's created by Trygve Reenskaug, the creator of the MVC-pattern.

Is it really the successor to MVC or just another pattern? And what are its pros and cons?

Was it helpful?

Solution

The impression I got is that it's not a successor to MVC so much as a complement, for example figure 5 in the artima article on DCI has both. I think it's supposed to help make the distinction between model and controller more sane, or maybe between different part of the controller or different parts of the model.

The basic idea seems to be to split logic for particular actions our of your data classes and move it to traits/mixins/whatever, one per (user) action. You'll have many small pieces of code, instead of a few large pieces. Also, it sounds like adding new mixins is supposed to be "better" than adding functionality to your base classes. The code for individual actions will probably (I think?) be more spread out, but code for different actions should be more clearly and obviously separated.

OTHER TIPS

Trygve makes a presentation of DCI in https://vimeo.com/8235394

DCI has been created to solve a problem in object orientation: it's too difficult to review OO code.

The code for one use-case in OO is typicall spread out between lots of classes. To understand how the code works, you must also know the relationships between objects in runtime. These relationships aren't set in code, they depend on the situation.

What DCI proposes is that code for a given use-case is separated out from the classes and put into a different artifact called context. Objects of different classes can enter into a relationship in this context and take part in interaction where they have different roles.

The whole point of DCI is to make OO code more readable!

That's how I would pitch it.

A good question and an often occurring question. The short answer is that it's a paradigm on it's own based upon the founding ideas of OO by Kay, Dahl and others. It was created by Trygve Reenskaug as you note with several goals in mind. One of them being tha aim of making IO operations first class citizens of the program. (not IO as in disk operations but all communication between two different objects). Another important goal of DCI is to split what the system does (functionality/behavior) from what the system is (data)

I think improved system comprehension is a huge win for any organization, but you could also make the case that DCI is an improvement on MVC due to the following additional factors:

  1. Cleanly separating system behavior and data provides numerous benefits to data aggregation activities including more performant real time analytics due to smaller footprint of domain objects.
  2. Data object and behavior object reuse is much easier across functional divisions when they have their own place to live rather than being particulates as if randomly placed across a subset of the mixed data/behavior objects in a system.
  3. As BDD is becoming the defacto agile methodology, the organization will be leap years ahead of the rest of the industry in this practice and possibly a role model for other like minded organizations.

It totally looks to me as the Policy based design by Andrei Alexandrescu in Modern C++ design, however that work is more low level, DCI looks like an architecture with parts of methodology (use cases drive the design).

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top