On logic in a Rails app, revisited 6 years later
alisnic.github.io
On logic in a Rails app, revisited 6 years later
1–10 of 33 posts
Re: On logic in a Rails app, revisited 6 years later
#2I'm currently building a Rails app with a event driven development (EDD) approach. This post makes me tingle.
After building apps with easily way to much logic in controllers, EDD feels like a much cleaner approach for long term scale. But finding the right EDD approach that feels like "the rails way" has sparked a lot of debate within our team, especially around the "does this actually help" argument.
I'm petty curious about others experiences :)
Re: On logic in a Rails app, revisited 6 years later
#3A lot of discussion I heard around writing idiomatic Rails led to really fat models. Given the number of database trips back and forth with ActiveRecord, it didn't end well.
Eventually as the system grew it was much better to have bulk-interfaces of data-only for reads that completely bypassed ActiveRecord. Logic in controllers was also eventually factored out and re-used elsewhere.
My experience is that a lot of advice for Rails centers around small-to-medium size applications, and of course practices that are efficient and practical for apps of that size might not work exceptionally well in other scenarios.
Re: On logic in a Rails app, revisited 6 years later
#4The original post sounds very much like what Robert Martin is proposing.
Re: On logic in a Rails app, revisited 6 years later
#5Rails is opinionated and forces a literal sense of MVC pattern, its dogmatic, thus the fat controller or fat model phenomena
Re: On logic in a Rails app, revisited 6 years later
#6What jumped out at me was this:
> To give you some context, it was a time when I was starting to grow as a Rails/Ruby developer. I was reading a lot of blog posts on the topics and (as any young developer with a lot of self esteem) I started to have very strong feelings as to how Rails code should be written.
Lots of programming advice is like this -- people definitely make sure not to let being a beginner, or close to, stop them from lecturing people with a decade plus of experience building applications how to do things...
Re: On logic in a Rails app, revisited 6 years later
#7A lot of discussion I heard around writing idiomatic Rails led to really fat models. Given the number of database trips back and forth with ActiveRecord, it didn't end well. Eventually as the system grew it was much better to have bulk-interfaces of data-only for reads that completely bypassed ActiveRecord. Logic in controllers was also eventually factored out and re-used elsewhere. My experience is that a lot of adv…
A number of years ago I started decoupling my business logic from my controllers and models and now use the ActiveInteraction gem. It really makes a difference when you have multiple interfaces that need to deal with a specific action on a specific object without having to call a controller all of the time.
While idiomatic Rails is definitely possible, I've been bitten by coding errors in Models where specific validations are only ran on update and/or create. Now I just run a CreatePerson object which only has the specific functionality needed and is decoupled as much as possible from other sections.
Re: On logic in a Rails app, revisited 6 years later
#8Related: The "AnemicDomainModel" https://www.martinfowler.com/bliki/AnemicDomainModel.html
In other words, there should be another layer in-between your DAO (data access object, ORM, etc) and controller. The "Model" in MVC was never meant to represent a single row of a database in object form. A Model should have a DAO but a Model should not be a DAO.
Re: On logic in a Rails app, revisited 6 years later
#9spring boot enforces the idea of having a service layer between controller and model to act as a glue between the two, so the controller can focus on controlly things like authentication and handling request s/responses (http,ws,rmq,whatever) and the service can handle creating objects, reading/saving entities and making calculations.
It just makes things easier to digest because you know what resides where. If I returned to rails, I would be using this approach more.
Re: On logic in a Rails app, revisited 6 years later
#10We use this library to isolate business logic: https://github.com/cypriss/mutations