Thank you for taking the time to answer, and also to amw-zero below.
I think I understand more of the sentiment now.
> As soon as you pass around a `user`, someone will type `.posts` on it, or `.save`
I'm not much of a fan of the active record pattern, and I can see (have seen) how optimistic/naive developers can get in trouble - but I feel these are two separate problems:
> someone will type `.posts` on it
This doesn't have to be all bad, just make sure there was a join or include first - perhaps via a scope (eg: User.with_posts).
I suppose some rails apps end up doing "much more than crud", and then it can be easy to stumble. But I find that with some modicum of discipline, "fat models" can go a long way towards making "slim controllers" fall out naturally.
> someone will type.. `.save`, on it
This why I use AR objects, so I can do crud. Sure if dealing with "posts" (plural) you want to avoid: posts.map... save in favour of update_all.
And while there's save! - data integrity belongs in db constraints. But validations are a great tool for better ux and error feedback. The major problem today, is probably that you'd want to (only) run them as client side js.
I did delete this post, I'm not sure how it came back. I wasn't happy with my answer.
I would avoid any logic in the models, they already have 3 responsibilities (data gateway, data holder and validation).
For CRUD apps, Rails has competitors that can't be overlooked, there are alternatives: PostgREST, Hasura + Forst Admin provide full crud UI with borderline no code.
In all honesty, you don't have to look far. Elixir + Phoenix, which is not free of mistakes, manages to be a better Rails than Rails itself. The validation is isolated, the database access is isolated from the model, no autoloading is involved.
I think I understand more of the sentiment now.
> As soon as you pass around a `user`, someone will type `.posts` on it, or `.save`
I'm not much of a fan of the active record pattern, and I can see (have seen) how optimistic/naive developers can get in trouble - but I feel these are two separate problems:
> someone will type `.posts` on it
This doesn't have to be all bad, just make sure there was a join or include first - perhaps via a scope (eg: User.with_posts).
I suppose some rails apps end up doing "much more than crud", and then it can be easy to stumble. But I find that with some modicum of discipline, "fat models" can go a long way towards making "slim controllers" fall out naturally.
> someone will type.. `.save`, on it
This why I use AR objects, so I can do crud. Sure if dealing with "posts" (plural) you want to avoid: posts.map... save in favour of update_all.
And while there's save! - data integrity belongs in db constraints. But validations are a great tool for better ux and error feedback. The major problem today, is probably that you'd want to (only) run them as client side js.