4 ms·
Abstractions are leaky. [1] ORM systems are highly complicated abstractions. Most of your developers will use them without understanding how they work. In man
by mbrock 12y ago
Abstractions are leaky. [1]
ORM systems are highly complicated abstractions.
Most of your developers will use them without understanding how they work. In many cases, the only way to understand how they work is to read the source code.
They have magic features that are advertised as convenient but when they inevitably do something you don't want them to do you'll tear your hair out trying to circumvent them.
They put lots of complicated weird stuff in your stack traces so when something goes wrong with "the database stuff," which is probably going to happen every day, you will feel confused and overwhelmed.
ORM was famously referred to as "the Vietnam war of computer science" by Ted Neward. [2]
There's a point that I think is even more important than the unruly and bewildering complexity of ORM, but I'm not sure I know how to formulate this point.
One way to formulate it would be to point out that your dichotomy of two choices is missing an alternative, so I present:
3) Code your data access in a separate module exposing query & save functions that make sense within your domain model.
In a reasonably complex system, this module might consist of fifty functions that concatenate SQL strings or whatever. In most cases, I'd bet money that rewriting this module to support some other data storage—especially if there are integration tests—would be easier and more pleasant than switching your ORM and then dealing with the random problems that will inevitably occur.
And when some query fails or is slow, the developer issued to fix it will just go into the file, find the query, and change it. It's simpler, there's less obscure technology to worry about, fewer things to get angry at.
[1]: http://www.joelonsoftware.com/articles/LeakyAbstractions.html http://www.joelonsoftware.com/articles/LeakyAbstractions.htm...
[2]: http://blog.codinghorror.com/object-relational-mapping-is-the-vietnam-of-computer-science/ http://blog.codinghorror.com/object-relational-mapping-is-th...
- tracker1 12y agoAlternatively.. wrap each domain's data as a separate micro-service, with a convenient API... Though it really depends on how you can break down the boundaries of your application's data. Then you can persist/represent that data however you like.
- neumino 12y agoYou should check out thinky. Because of the chainable query language you don't have to build a new abstractions. You can just use the same. Meaning that there is nothing (or very little) to learn yp switch from the driver to thinky.
- politician 12y agoPreprocessed prepared queries that are shipped along with whatever package is using them is a far easier solution than quirky ORM tools that can do the simple things, but have a tendency to break on the harder things or encourage an authoring style that destroys performance. That said, I think the world could use a CoffeeScript-esque transpiler for targeting SQL. Preferably with some kind of frontend/IL/backend separation, so that everyone can take a crack at replacing the awful SQL syntax.