3 ms·
I admit the comment was meant to be a bit tongue in cheek but it doesn't appear to have had that impact. My intention wasn't to be condescending or anything lik
by icxa 7y ago
I admit the comment was meant to be a bit tongue in cheek but it doesn't appear to have had that impact. My intention wasn't to be condescending or anything like that as others have taken it.
A better argument would have been to explain why ORMs are bad.
In my view:
- they encourage bad data modeling practices. Eventually there will come a time where the way your ORM maps your data model to physical tables will be inefficient. Maybe you really have event based time series. The impedance mismatch becomes exacerbated.
- they are an extremely leaky abstraction. It is hard to think of a more widely used abstraction that leaks more. You have to be familiar with your ORM's SQL generation. Every single comment here has admitted that yes you eventually do have to drop down into raw sql, so this part isn't even subjective at this point. The article is about leaky abstractions, ORMs are the poster child for them.
- On the other side of things, there are simpler abstractions between SQL and ORM that provide more value comparatively for the leakage, and my argument was you would be better off having simple leaky abstractions than one massive behemoth of an abstraction that leaks more than a waterfall.
- Really hammering the point home here on the leakiness, for being such a leaky abstraction, after it is all said and done, in my view they really don't provide you with all that much value, given that you have extensive experience working without them (the source of my seemingly condescending point about experience and some languages guide you to never working without them).
I can just as easily use my code generation tools to have "less code to write", and map some functions to SQL statements using my language's favorite DB drivers, use a battle tested and proven SQL migration and schema tool, and I can do this just as fast as any experienced ORM developer.
In this view, just like we have had the movement away from big massive monolithic frameworks to smaller opinionated sets of libraries stitched together with simple glue code, your ORM is the massive monolith in this case, and your simpler tools like code gen and migration tools are the smaller libraries.