Ruby On REST 2: Representers and the DCI Pattern

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.<p>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.<p>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.

Can anyone double-check my interpretation of this?<p>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.<p>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.<p>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 <i>anyway</i>, 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.<p>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.

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.

There are many reasons to push application logic as low as possible in an application stack.<p>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.<p>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.

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.