2023/05/15/my-issue-with-orm/

[utterances-bot]

My Issue With ORMs · Preslav Rachev

I am a software engineer with a decade-long experience developing software using Java, Go, and Elixir.

https://preslav.me/2023/05/15/my-issue-with-orm/

[christophberger]

I know these things are tedious, and type conversion is among the most boring stuff in programming

In an optimistic view of the near future, AIs will take over the boring parts of programming, but only those. 🤖

[aschwin]

I do get your gist. And for some parts I do agree somewhere. But, like always, it depends and more roads lead to Rome etc.

The problem with fat models can be tackled by domain boundaries. Either tucked away underneath micro-services or just plain and simple separated parts of your application. DDD helps a bit with this, but I'm not a DDD zealot.

Within a domain boundary you use models that only carry what is needed within that domain. Orders have different criteria about 'customers' than the CRM part for example. Or timesheet and employee models carry different aspects depending on who is accessing them: the employee or the administrator.

Tucking away plain SQL in a Repository pattern might increase the risk of making these fat too. Or to overuse that pattern so far that it doesn't make sense anymore.

As always: it depends and start a discussion with your team members. Find what works for you and your team, but also try to look ahead into the future growth of the application.

A very good criteria might be: what might possibly change from the business perspective and how can we encapsulate these changes?

[nicolasbui]

Well you issues depends on the tools you are using. Learn to appreciate the tool you have until you've found a better tools or when you'll feel enough confident to create your own tool.

I overall appreciate ORM for the common tasks (about 70% of them are common). It's true that when things get complex, ORM aren't good anymore, it's a living nightmare .