Taming Large Rails Applications with Private ActiveRecord Models
kellysutton.com
kellysutton.com
I don't really understand why this would be an advantage in a large app.
It's more explicit, but then you have to slow down and add all those wrappers for active record stuff. I can also see it getting annoying/confusing if you have a mix of normal models and these models in an app that you are not familiar with.
When I think of and create a model I think of active record as part of that public interface. And unless I want to restrict stuff I would want the default to be exposed.
> The tangle of dependencies, callbacks, and relationships can grind your entire engineering organization to a halt.
> Why do we want encapsulation? As an organization grows, any public interface will eventually be used.
> So we start to take a defensive approach to modeling, only making public what we are sure that we can support. This makes these models easier to support because they have a smaller surface. They are easier to change internally, too, because there are fewer different uses.
> It has also helped teams collaborate and create contracts for interactions.
"but then you have to slow down and add all those wrappers for active record stuff" you also have to slow down to resolve technical debt and deal with collaboration, among other things. It seems that the approach they describe is giving them a positive opportunity cost. There are always pros and cons.
"And unless I want to restrict stuff I would want the default to be exposed" the article explicitly says they wanted to restrict stuff.
My best guess is trying to limit instances of AR models, encapsulating them in a new data access pattern versus traditional Active Record/ORM; in other words, misusing AR against how it was designed.
A far better approach is to put related methods in concerns. When you do this based on features, lets say a concern called "SyncToTrello" that contains all the methods on lets say a "Task" model that are related to syncing to Trello. So when I have to refactor or debug the sync, I just open up the concern and look at the handful of methods that are related to just that. Rather than having to scroll through a 500+ loc Task model.
Using concerns has been a great way to tackle growth in our Rails application.
Rails made a choice to use the active record pattern instead. This article is about adapting an existing application to a new pattern.