Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Rails: too many methods in model

TL;DR: I don't know how organise my logic domain classes.

I have the model "Application", this model is in the "core" of the App and is the way I "enter" and operate over other models like:

@application = Application.find(params[:application_id])
@application.payment.update_attribute 'active', true

or

   unless @application.report.status 

or

   @application.set_income(params[:income][:new_income])

so the models Payment, Income and Report are basically empty because I initialise the Application model and from there I do things "on cascade" to change the "subordinated" models. But now the Application model has more than forty methods and 600 lines.

I'm doing it right? For instance when I want to add a new Payment I like to do :

payment = Payment.create params  

inside the Application model because ActiveRecord "knows" how to handle the foreign keys automatically. I could create the payment inside the Payment model using:

application = Application.find(application_id)
params[:application_id] = application.id
self.create params

but this way, I need to set the Application.id manually and that looks more verbose and not elegant.

So --if I want to reduce my Application model--, should I create modules in APP/lib directory or should I move methods to the other models?

like image 692
aarkerio Avatar asked Nov 23 '25 08:11

aarkerio


1 Answers

should I create modules in APP/lib directory

Basically, yes, that's what you should do. Although I'd probably make them classes rather than modules. The pattern it sounds like you're after is called "service Objects" (or sometimes "use cases"). What this does is takes the logic from a specific operation you want to perform, and puts it in it's own self-contained class. That class then collaborates with whatever models it needs to. So, your models stay quite small, and your "Service Classes" follow the Single Responsibility Principle. Your controllers then usually call a single "service class" to do what they need to do - so your controllers stay pretty minimal too.

If you google "rails service objects" or similar, you'll find lots of great stuff, but here's some resources to get you started.

Service objects rails casts: https://www.youtube.com/watch?v=uIp6N89PH-c

https://webuild.envato.com/blog/a-case-for-use-cases/

https://blog.engineyard.com/2014/keeping-your-rails-controllers-dry-with-services

http://blog.codeclimate.com/blog/2012/10/17/7-ways-to-decompose-fat-activerecord-models/ (there's one section on service objects there)

Keep in mind, once you do start using service objects, you don't necessarily have to ALWAYS go through your Application model to get to the related ones. A service object might take an application_id and then do eg. @payment = Payment.find_by(application_id: application_id) and so you don't have to fetch the application instance at all and can manipulate the @payment variable directly.

The fact that Rails makes it "easy" and "pretty" to get to related models doesn't necessarily mean you should do it.

like image 174
joshua.paling Avatar answered Nov 24 '25 22:11

joshua.paling



Donate For Us

If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!