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