Thick models breed nasty code that's difficult to change later. Pull out of the models and you violate some of Rails' assumptions about design, and kill some DRY principles to boot. I still hold out hope that ActiveModel is the answer to some of this stuff.
The beauty of Rails is that for a certain model size and level of complexity, ActiveRecord just beats the pants off of traditional patterns. DTO? Why bother? The alternative--combining DB access with model logic--is vastly simpler for a good proportion of use cases, and not too terribly nasty until you hit the extreme cases. But it's definitely one of those things that makes experienced Java/Smalltalk OOers go "huh? isn't that a smell?" when they see Rails code for the first time. A few years ago, people started experimenting with the Presenter pattern in Rails: a layer between the view and the ARec model that would help to contain some of this stuff; the controller talks to that layer rather than hitting AR directly (for example, when rendering a complex view that requires touching multiple models, or processing a form that has no direct 1:1 database mapping). This has its own problems (vis-a-vis some logic duplication) but is super helpful in some cases (ever designed a complex search form?). Tim's advice about the API stuff is well-taken, although whenever I hear "sooner or later" there's a portion of my brain that screams "YAGNI!". And then the portion of my brain that's been screwed repeatedly by the other brain screaming "YAGNI!" kicks in. And then things get messy. If you can find a nice pattern for keeping models thin, by all means do so. The struggle I always have is with consistency: do you map all of your ARec models to "proper" models, or just some? If you only map some, well, that sucks: it's inconsistent. But if you map all of them you're introducing a pattern that the team has to own, which may be nonstandard and or difficult to maintain; you're now responsible for whatever design decisions came with the move away from ARec. Brian On Sun, Sep 11, 2011 at 8:35 AM, Stuart Liston <[email protected]> wrote: > Hi again guys > Since I know you like to get philosophical, I thought I'd throw out another > question, one that's been bothering me a little. The answer may be obvious > to everyone except me. > What do y'all think about having business logic in ActiveRecord model > classes? > I often see a bunch of methods in ActiveRecord classes, but that seems to be > contradictory to the advice in Uncle Bob's Data Structures vs Objects > chapter in Clean Code. > It would be interesting to learn where everyone sits on this one… > Do you mix it up together? Do you always write your business objects as a > layer of abstraction to provide something of an api for your AR model > classes? Does it depend on the size of the app? > Cheers, > Stu > > -- > You received this message because you are subscribed to the Google Groups > "Ruby or Rails Oceania" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/rails-oceania?hl=en. > -- You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en.
