3 ms·

Ruby On REST 2: Representers and the DCI Pattern

28 points by andrzejkrzywda 15y ago

yxhuvud 15y ago
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.
hmottestad 15y ago
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.
extension 15y ago
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 15y ago
  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 15y ago
    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 15y ago
      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.
Semiapies 15y ago
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.
deleted 15y ago
[deleted]
Groxx 15y ago
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 15y ago
  >> 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 :)

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.

hmottestad 15y ago

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.

extension 15y ago

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 15y ago
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 15y ago
  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 15y ago
    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.

Semiapies 15y ago

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.

deleted 15y ago

[deleted]

Groxx 15y ago

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 15y ago
>> 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 :)