

Ruby On REST 2: Representers and the DCI Pattern - andrzejkrzywda
http://nicksda.apotomo.de/2011/12/ruby-on-rest-2-representers-and-the-dci-pattern/

======
yxhuvud
I don't get it. If your models grow too large and do too much, then you
refactor them into models that each have a single responsibility.

DCI could still be a good idea if the abstraction it provided is good. I'm not
convinced that is the case. The main problem I have with it is that it doesn't
scale down as well as MVC do, meaning that if you start out with it you will
have a lot of mostly empty classes. No gain at all in that case.

In the other scenario when you have some really big models, then you should
refactor them anyhow. Will the DCI pattern be a good fit then? Perhaps,
perhaps not.

------
Groxx
Can anyone double-check my interpretation of this?

Good fat model design: break up units of behavior and related variables into
modules, and include them in the model. Few people actually break them up, but
that's unrelated to what's "good". Advantages: related behavior is
encapsulated, likely in separate files, and methods are always available down
the pipeline. Disadvantages: huge numbers of methods at any given time.

DCI design: .extend those modules into the models as you need them.
Advantages: related behavior is encapsulated, likely in separate files, and
code is declarative about what it intends to be used for and cannot be used
otherwise. Disadvantages: have to new.extend(YourModule) every time.

If that's the case, I can see the advantage around guaranteeing things aren't
using it outside of the controller-declared intended usage. More controllable
/ predictable code, basically. But breaking things into modules is a good idea
_anyway_ , regardless of if people actually do so, and aside from the
increased control I don't see how this is different than module-including
models.

Better, I'll admit, but they seem to be claiming ponies and rainbows that'll
knock your socks off, when what they're offering is just a style choice (many
modules per model) + per-instance mixins rather than per-class, which seems to
imply to me that they're allowing a lot more manipulation of the models
further down the rendering pipeline than is generally recommended in MVC.

~~~
knewter
>> which seems to imply to me that they're allowing a lot more manipulation of
the models further down the rendering pipeline than is generally recommended
in MVC.

Of note, is that the inventor of MVC is also the inventor of DCI.
Consequently, I think you'd agree that perhaps he didn't agree with you :)

------
extension
Can I solicit some dumbed down explanations of DCI? I've read a few articles
about it, as well as the Wikipedia entry, and I still have no idea what it's
all about.

~~~
andrzejkrzywda
The metaphore of DCI is a theatre. The context is the director. Chooses who
plays what, instruct them how to do it and then let them play.

Theory:

1\. Expose use-cases (context) as first-class citizens of your code.

2\. Each use-case selects which objects are needed for this use-case.

3\. Extend the objects only with the roles that are needed in this use-case.

4\. Start the interaction.

Example:

Buying a product.

1\. UserBuysAProduct object, that can be executed.

2\. Objects/actors needed: user, shop

3\. Extend user with a Buyer role and shop with ProductCatalogue and
OrderManager.

4\. call shop.buy_product(user, product)

~~~
extension
Ok, so this is a way of decomposing just the domain model into smaller parts:
a minimal model, role objects that extend it for particular purposes, and
context objects that assemble a set of models and roles for a particular use
case.

The rationale is, presumably, that you can add and change particular use cases
independently of each other and the core model.

Right?

~~~
andrzejkrzywda
Yes, exactly.

The idea is that the Data doesn't change that often, so it's kept separate
from the things that change frequently - roles, use-cases.

Exposing use-cases is also an important goal, usually they are scattered
across the codebase.

------
hmottestad
There are many reasons to push application logic as low as possible in an
application stack.

Let me give you an example: The people designing the database did not make the
"email" column check that the address was valid. Then someone designing a new
top-tier application (say android app) forgot to add the email check to the
app. Then a user mistakenly puts his phone number into the field and now the
auto-mailer (designed in 1998) breaks because the developer assumed the
database would at least provide a syntactically correct email address.

Pushing logic down as low as it goes, or adding an abstraction layer
(middleware) to the system greatly reduces overall maintenance cost. So doing
some vertical scaling here and there is more cost effective.

------
Semiapies
Does anyone have links to samples of DCI-structured code other than the very
small money-transfer example Google turns up? I'm really intrigued by the
idea, but I'd like to look at some examples with multiple contexts and roles
acting on the same data classes.

