3 ms·

I've had the pleasure to work on such kinds of Rails apps a few times. It was almost magical, compared to all the other common Rails apps with their ever accumu

by berkes 3y ago

I've had the pleasure to work on such kinds of Rails apps a few times. It was almost magical, compared to all the other common Rails apps with their ever accumulating fat models, complex controllers, untestable- coupled classes and so on. One had this what you describe: everything in /lib, and the MVC merely delegating to that. MVC downgraded to what it should be: plumbing that binds together your domain stuff. The other did something similar but had it in gems (bound as Railties/engines). IT was a bit more cumbersome, as one had to release a new gem before being able to integrate it in the rails app. It forced a very solid separation of concerns.

cies 3y ago
> compared to all the other common Rails apps with their ever accumulating fat models, complex controllers i interpret fat model as: what can be move to the model, sits better in the model (directory). things that cannot be moved to the model: the request, the response, the session. not set in stone, but usually this works. what i regret about older Rails code i wrote was the gluing of all biz logic to ActiveRecord ORM models (akin to, yuck, Hibernate entities), that also contain DOAs, form validation and all business logic. now i tend to split these out: form dtos that do validation, repos with queries, simple record classes, etc. fat signals homogenous big thing, but is actually where most of the application lives. i coudl call it lib as well.
- berkes 3y ago
  Except that Models are also Records. So by definition they don't separate concerns: for one the separation of concerns between "storing/retrieving stuff" and "all the business logic stuff". This lack or SoC, invites other tight coupling: For example, in Rails we commonly couple our models to our database design. You need a Medicine Adjustment? Better have a "medicine_adjustments" table, eventhough its more an Event than a record. Sure, you can pick and choose pieces of ActiveModel, and build models that aren't backed by database-tables, or by multiple tables. I do that all the time. But its far easier to just tightly model each Model around a Record/db-table. And because it's easier, its what most of us (especially juniors not bitten by it years later) will do: the easy way. In the book "Growing Rails Applications"¹ has the -IMO- best practical patterns to solve this, but it goes right against the "you open a rails app and know what's happening": neat patterns, well manageable, and well documented, but very non-railsy. https://rubyandrails.info/books/growing-rails-applications-in-practice https://rubyandrails.info/books/growing-rails-applications-i...

by berkes 3y ago

cies 3y ago

> compared to all the other common Rails apps with their ever accumulating fat models, complex controllers i interpret fat model as: what can be move to the model, sits better in the model (directory). things that cannot be moved to the model: the request, the response, the session. not set in stone, but usually this works. what i regret about older Rails code i wrote was the gluing of all biz logic to ActiveRecord ORM models (akin to, yuck, Hibernate entities), that also contain DOAs, form validation and all business logic. now i tend to split these out: form dtos that do validation, repos with queries, simple record classes, etc. fat signals homogenous big thing, but is actually where most of the application lives. i coudl call it lib as well.

berkes 3y ago
Except that Models are also Records. So by definition they don't separate concerns: for one the separation of concerns between "storing/retrieving stuff" and "all the business logic stuff". This lack or SoC, invites other tight coupling: For example, in Rails we commonly couple our models to our database design. You need a Medicine Adjustment? Better have a "medicine_adjustments" table, eventhough its more an Event than a record. Sure, you can pick and choose pieces of ActiveModel, and build models that aren't backed by database-tables, or by multiple tables. I do that all the time. But its far easier to just tightly model each Model around a Record/db-table. And because it's easier, its what most of us (especially juniors not bitten by it years later) will do: the easy way. In the book "Growing Rails Applications"¹ has the -IMO- best practical patterns to solve this, but it goes right against the "you open a rails app and know what's happening": neat patterns, well manageable, and well documented, but very non-railsy. https://rubyandrails.info/books/growing-rails-applications-in-practice https://rubyandrails.info/books/growing-rails-applications-i...