Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ways to Decompose Fat ActiveRecord Models

blog.codeclimate.com

Post reply on HN
Print view View original

11–20 of 21 posts

Re: Ways to Decompose Fat ActiveRecord Models

#11

Post by brynary »

tmorton wrote: post #8
ljoshua wrote: post #5

This is more of a theoretical question, but at what point does a project become large enough that concerns like this begin to truly matter? When doing a small, limited-use project, it seems often that trying to follow "best practices" like avoiding fat models would be more trouble than it's worth. And yet I've worked on larger enterprise-scale projects that have most certainly benefited from following this and other…

I don't have any research, just a rule of thumb: refactor when it hurts. In my experience, it's easy to go too far in the other direction, trying to craft perfectly generic code on the first pass. That doesn't work very well. It's important to have a meta-awareness while programming - how firm is your grasp on the code? How confident are you that your changes will do what you expect? At some point, you feel that gras…

That's a great summary. It's easy to lose that meta-awareness, even if you're an experienced coder. You are holding a hammer, and the nail isn't going in, so your first instinct it "hammer harder". But usually it means you need a screwdriver.

Re: Ways to Decompose Fat ActiveRecord Models

#12

Post by cunac »

LaSombra wrote: post #2

I like Ruby on Rails, but "coming" from a Java background I find it odd to have lots of stuff in the models instead of using utility classes or services.

you shouldn't have so many if at all utility classes in java as well services should be used to compose process behavior not domain behavior IMHO service -> enroll user user -> domain behavior eg. concrete distinct action in responsibility of that domain object I hate when people write code like this get attributes of object do something with attributes set attributes back

instead having operation on object doing this and clearly encapsulate behavior and hopefully data as well

Re: Ways to Decompose Fat ActiveRecord Models

#13

Post by ollysb »

ljoshua wrote: post #5

This is more of a theoretical question, but at what point does a project become large enough that concerns like this begin to truly matter? When doing a small, limited-use project, it seems often that trying to follow "best practices" like avoiding fat models would be more trouble than it's worth. And yet I've worked on larger enterprise-scale projects that have most certainly benefited from following this and other…

I try to follow a gradual approach to decomposition. When I start to get a lot of related methods I wrap them in a module, but still within the model definition(I just include the module immediately after definition). From there I might just move it to a separate file as is or perhaps I turn into a decorator and add an accessor for it on the model e.g.

  class Retailer
    ...
    def metrics
      RetailerMatrics.new(self)
    end
  end

  class RetailerMetrics
The biggest danger with any of the patterns from the article is that you start using them before you actually need them. Then you just end up with a lot of complexity for no benefit.

Re: Ways to Decompose Fat ActiveRecord Models

#14

Post by brynary »

mattmanser wrote: post #6

Ok, time to embarrass myself due to lack of Ruby/programming knowledge. A few questions that perhaps someone can clear up as from my OO perspective this, to me, is all over the place. I must admit I'm only just getting started on Ruby. Firstly, that doesn't look like the strategy pattern to me, isn't it back to front? And even if it were, what the hell are you doing? You do not pass the user to the authenticator, you…

Good points/questions. I'll try to respond to each...

* RE: Strategy pattern. My understanding of the strategy pattern is it simply refers to "algorithms are encapsulate and can be selected at runtime". (http://en.wikipedia.org/wiki/Strategy_pattern)

* RE: New class per object query. Agreed that grouping these can make sense. Had to keep the example brief.

* RE: Events. That's another approach -- thanks for the suggestion.

* RE: "View Model" vs. "View". I had it as "View Model" in the original draft and got feedback from reviewers that they are usually called just "Views". :-) I've heard it both ways .

Thanks for the questions!

-Bryan

Re: Ways to Decompose Fat ActiveRecord Models

#15

Post by brynary »

ollysb wrote: post #13
ljoshua wrote: post #5

This is more of a theoretical question, but at what point does a project become large enough that concerns like this begin to truly matter? When doing a small, limited-use project, it seems often that trying to follow "best practices" like avoiding fat models would be more trouble than it's worth. And yet I've worked on larger enterprise-scale projects that have most certainly benefited from following this and other…

I try to follow a gradual approach to decomposition. When I start to get a lot of related methods I wrap them in a module, but still within the model definition(I just include the module immediately after definition). From there I might just move it to a separate file as is or perhaps I turn into a decorator and add an accessor for it on the model e.g. class Retailer ... def metrics RetailerMatrics.new(self) end end…

Yes! Gradual is they key. Your architecture should scale up gradually to handle the app complexity.

Re: Ways to Decompose Fat ActiveRecord Models

#16

Post by jweir »

damoncali wrote: post #7

Perhaps it's my lack of training or the projects I work on, but I've never seen a Rails model so large/cumbersome as to justify even one of these techniques. Is this a case of fixing the wrong problem?

I have a project which will benefit from Bryan's advice.

There are models which are overly large (the project started as a Rails 1.2 project now at 3.0). The project has moved through different hands and the cruft and bloat has built up.

I look forward to applying some of Bryan's points to these models.

Re: Ways to Decompose Fat ActiveRecord Models

#18

Post by brynary »

chrisconley wrote: post #17

Cool stuff. @brynary, how do you organize your app? Are all seven techniques dumped into app/models or do you keep each technique in its own directory?

I wrote about that bit in my previous post:

http://blog.codeclimate.com/blog/2012/02/07/what-code-goes-i...

But really, in short, don't worry too much about it. Plan on reorganizing once or twice as you find what works for you.

-Bryan

Re: Ways to Decompose Fat ActiveRecord Models

#19

Post by ljoshua »

brynary wrote: post #11
tmorton wrote: post #8

Earlier quoted context omitted.

I don't have any research, just a rule of thumb: refactor when it hurts. In my experience, it's easy to go too far in the other direction, trying to craft perfectly generic code on the first pass. That doesn't work very well. It's important to have a meta-awareness while programming - how firm is your grasp on the code? How confident are you that your changes will do what you expect? At some point, you feel that gras…

That's a great summary. It's easy to lose that meta-awareness, even if you're an experienced coder. You are holding a hammer, and the nail isn't going in, so your first instinct it "hammer harder". But usually it means you need a screwdriver.

I agree, great summary, thanks for the insight.

Re: Ways to Decompose Fat ActiveRecord Models

#20

Post by programminggeek »

Ok, let me throw out a different perspective, why are you even using an ActiveRecord Model as your entities in the first place. That in itself violates the Single Responsibility Principle by attaching the persistance mechanism to the entity itself.

What if your entities were just objects that held data and did validation, but you let use case objects determine the behavior of your system beyond that? Data persistance at that point is literally persisting your entities to the DB.

Then you use the DB much more like you would a filesystem - to retrieve and save data. It doesn't determine your model, it just stores and retrieves your data.

So, you end up with 3 types of things in this system... entities, use cases, and data gateways.

Your data gateways can still use AR if you want, or something else, it doesn't matter.

This isn't my idea, Uncle Bob lays it out better than I can here: http://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-arch...

Post reply on HN