[RangerScience]

The Rails apps I’ve worked with where there was an ORM mess (which yeah… is all of them) it’s extremely clear that the mess is the normal “too fast” software development mess. Sure, it’s worse because it’s the ORM (and/or sharp knives), but it’s also always been the case that I can clean it up with better use of Actuve Record.

Also, I’ve worked with some pretty gnarly pure-SQL systems that had essentially the same kinds of problems.

It’s all just variations on “saving hours of planning with months of work” kind of things.

[Tainnor]

Rails and especially DHH particularly encourage not having any sort of separation between your domain objects and your persistence (and even your views), which is why N+1 queries are so goddamn common and why people are going to put confirmation mail logic in model callbacks etc.

[RangerScience]

> your domain objects and your persistence

Hmm. Thinking over my career...

Maybe I don't know what you mean by "domain objects", "separation", and "persistence", but when I think over the stuff I've worked on in my career, and the problems I've seen in codebases...

Yeah, I think I'm with them on this - your domain objects and your persistence should pretty much be the same thing. There's gonna be a few exceptions (and, ofc, you can do a shit job building the models), but I expect those to be short-lived and small.

Otherwise, you shouldn't have domain _objects_ doing all that, you should have functions operating on data, and the data is pretty much always going to be either (1) some incoming hash or (2) some database record; then you group the functions into handy modules for humans. And then they're not domain _objects_.

Do you have a good example of a "domain object" that you think really _should_ be heavily separated from persistence?

PS - The one time that comes to mind that might fit, the data I wanted to persist was essentially logging data on the operation that was performed on other data.

PPS - N+1 queries are kinda trivial to resolve in most cases in Rails? There's core ORM functionality for it.

PPPS - Yeah, don't put your confirmation mail logic in the model callback, that's a bad plan.

Fake edit: Like, you either have data you want to persist, or you have data you're transforming. If you're transforming it, it's temporary, and either I don't understand what a "domain object" is, or I think you'd make a mistake to make your temporary data into a domain object.

[Tainnor]

Your business logic should not be tied your persistence, that's what I mean by it.

By "domain objects" I don't mean that you need to embrace OOP, they could be simple structs without any associated logic.

> PPS - N+1 queries are kinda trivial to resolve in most cases in Rails? There's core ORM functionality for it.

The problem isn't that you can't fix N+1 queries in Rails, it's that it's incredibly easy to create them by accident because your ActiveRecord objects carry a DB connection around everywhere, even in views.

[RangerScience]

Ah! Then we're in agreement :)

And yes, Rails makes it easy to make "unthinking" mistakes - like, you should prep your ActiveRecord objects in the controller so they've got all their data for the view, but, because you don't have to...

Blessing and a curse. You can turn it on and pretty much immediately get started, but that doesn't mean you know what you're doing...