I have yet to see a software project where ActiveRecordish ORMs did not end up making the modelling of business processes and translation of use cases into code overly messy and complicated, Rails or Django.
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.
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.
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.
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.
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...
I can’t speak for rails’s ActiveRecord but I don’t think DjangoORM is worse than any other ORM in that regard. It’s probably one of my favorite ORMs. I don’t think I’ll ever really use it again but that includes every other ORM.
I mean there is a clear difference in how ORMs that use the data mapper pattern like Hibernate or Entity Framework etc. ultimately allow for a cleaner overall application architecture vis-a-vis ActiveRecord (the pattern) which usually ends up leaking throughout the entire application.
I think we agree. I don’t think there is that much difference between ORM patterns (and I’m sorry I misunderstood you) because they all eventually become more trouble than they are worth in larger and more serious projects. I agree that you can probably go further with data mapper pattern ORMs, like EF, but I’m not sure I think the same is true for something like DjangoORM vs SQLAlchemy. On the flip-side a lot of projects will do fine with any ORM and never run into issues over their lifecycles.
Though in a world of SQLC (and similar) I’m not sure what ORMs are really solving for anyone anymore.
