Hacker News Reader

Comment by jkoudys | Hacker News Reader

I've always felt so alone in my distaste for ORMs. They often lead to at worst taking way more data than you need and manipulating it all in a language that's not very good at it, or at best running some kind of query-builder which takes a far more complex configuration to get the same data that a simple query could. Objects make much more sense as something to build from a query, not something to be queried themselves.

If the tide is turning against ORMs, it probably has a lot to do with the rising love for fp that this author covers. Languages like SQL are declarative, as is fp, so that approach feels more natural to people these days.

View on HN

ORM is one of those "dark grey boxes" we often have to deal with. When they work as intended, they can indeed save time, but when they don't, you have to fiddle in an organic fashion to solve or work around the problem, because otherwise they are thousands of line of code if you wish to dig in code-wise.

As an alternative, use stored procedures with Dapper, or use smaller sub-helpers that prepare most of the SQL statements or sub-statements for you but don't outright hide it. They assist in creating SQL (and prepared statement parameter mapping), but only assist, and are kept to less than a few hundreds of lines of code.

Other dark-grey-boxes include URL route mappers, seen in MVC stacks, and HTML formatters, such as Razor. When they don't work right you'll waste many many hour fudging with them. I'd often rather replace the URL router with Case/switch statements: it would be easier to debug; so what if it's a bit more typing. It's a white box.

"As an alternative, use stored procedures with Dapper"

I understand using Dapper. It is exactly what I want in an ORM. But I've yet to see anyone make a convincing argument for using stored procedures over using parameterized SQL.

I tent to consider database querying as constraint oriented programming, so indeed it does not fit either OOP or FP model. However, I do think that mapping database records to objects can be useful once they are in the program space.

There's loads and loads of literature on this, but I never felt it as strongly as with Angular. No matter how you represent the data, you want one layer of the code to be responsible for final dispensation on the organization and data munging (maps to arrays, arrays to maps, undefined -> empty set, etc). Everything else in the system should treat those fields in a homogeneous manner, and if you don't like the way the data is shaped, you know exactly where the problem is.

ORM or not, there's going to be a clear spot in the code where any mismatches between the backend and the frontend will be found. Or you're going to play whack-a-mole forever, and ramping up new employees will be a strain.

Reply on news.ycombinator.com