3 ms·
We had many problems using ORM's in production: - performance issues (DB calls in a loop the worst offender) - various obscure bugs due to the concept of "flu
by kgeist 5y ago
We had many problems using ORM's in production:
- performance issues (DB calls in a loop the worst offender)
- various obscure bugs due to the concept of "flushing" (for example, we just deleted an entity, but it's still retrievable from its repository in the same transaction, which breaks logic)
- additional cognitive load because you have to learn ORM's concepts and how it maps to both DB and your domain model
- you have to either add ORM-specific attributes directly to domain objects (which is leakage of infrastructure details to the domain layer) or write tons of functions which convert ORM models to your domain entities and back
So in new code we now use raw SQL and we don't find it all that hard - it's easy to maintain and doesn't take a lot of time. It's problematic with complex aggregates, but our models tend to be anemic.
There's the hypothetical "what if you'll want to change the DB" but all DB calls are encapsulated in the infrastructure layer, so we'd only need to rewrite repository implementations. And you can migrate to a new DB gradually, microservice by microservice, and a typical microservice won't have more than ~20 repositories, so it's pretty manageable.