Ways to Decompose Fat ActiveRecord Models
blog.codeclimate.com
Ways to Decompose Fat ActiveRecord Models
1–10 of 21 posts
Re: Ways to Decompose Fat ActiveRecord Models
#2I 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.
Re: Ways to Decompose Fat ActiveRecord Models
#3Good article. Concise. Something I will come back and reference.
Re: Ways to Decompose Fat ActiveRecord Models
#4I 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.
Coming from a java background to rails I found it entirely refreshing that everything wasn't in a utility class or service. Decomposition of a system using utility classes and services(in the n-tier style) is to make your system more procedural rather than more OO. This article is encouraging more OO patterns, closer in spirit to DDD. The article doesn't actually go into this but all of the techniques described can be used to compose a class so that there is still a single API for each model in your system i.e. the decomposition into policies, decorators, services(of the domain type) etc. can be hidden from the user behind the model api.
Re: Ways to Decompose Fat ActiveRecord Models
#5This 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 practices.
Anyone know of any research or work on where the tipping point is for following increasingly complicated patterns and practices?
Re: Ways to Decompose Fat ActiveRecord Models
#6Ok, 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'd pass the authenticator to the user constructor.
The way you've chosen is very brittle, it's a sure fire way to accidentally shoot yourself in the foot later on when someone accidentally deletes the authenticator or adds a new code path that doesn't contain one.
I also don't understand why you're creating a new class per object query? Ditto for the policy stuff. Why not just use a repository object if you don't want to clutter your main class. Like OrderRepository.GetByCompany(Id).
As for point 7, I don't understand why you're not completely extracting the facebook integration from the comment class. Does Ruby not have events? Why aren't you firing an event that the facebook integrator that initialized on the user object subscribed to? i.e. make a facebook integrator that registers itself on the user object creation.
Also, "View Model" not "View Object", that's what they're called, a lot of other frameworks already use them.
Re: Ways to Decompose Fat ActiveRecord Models
#7Perhaps 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?
Re: Ways to Decompose Fat ActiveRecord Models
#8This 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 grasp slipping, and then it's time to refactor.
Re: Ways to Decompose Fat ActiveRecord Models
#9Perhaps 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?
Not all apps require these techniques to stay maintainable. My background is working on larger Rails apps, built up over multiple years by teams of 6+ people, so the post is shaped by those experiences.
Re: Ways to Decompose Fat ActiveRecord Models
#10I 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.
Coming from a java background to rails I found it entirely refreshing that everything wasn't in a utility class or service. Decomposition of a system using utility classes and services(in the n-tier style) is to make your system more procedural rather than more OO. This article is encouraging more OO patterns, closer in spirit to DDD. The article doesn't actually go into this but all of the techniques described can b…
That's a good point. It sounds like what you're describing is essentially a Facade. That can be useful if you need coordinated objects to manage complexity, but want to keep it simple for clients to use that part of the application. I sometimes create a Facade for a Ruby module that is a package of fine grained classes.