4 ms·

> 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 m

by 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 cies 3y ago

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...