

I'm not sure if ORMs are an anti-pattern - dustingetz
http://www.dustingetz.com/im-not-sure-if-orms-are-an-anti-pattern

======
jrockway
How does using an object database exclude transactions? Transactions make as
much sense for rows in a database as they do for objects in a database or even
objects in memory. Atomic object graph mutations are an essential feature of
any concurrent system. It just won't work any other way.

The reason to use an ORM instead of an object database is twofold. One, it's
safer to use a working database and put some libraries on top of it than it is
to write your own database. Do _you_ want to write unit tests for the deadlock
detection algorithm? Two, sometimes you're writing an online transaction
processing application (99% of web applications) with fixed domain objects,
but you want the flexibility to slice-and-dice the data in the future. In that
case, an ORM makes your relational database look like an object store to the
application (which is exactly what it wants), but it also lets you play with
the data in Excel if you want to. The key is not that the data is relational,
but that it's in a standard format that other software understands.

Ultimately, there are three kinds of applications that you can write. One is
what most software is; the user interacts with the application and generates
state along the way and you want to record that state and act upon it. In that
case, an object database is perfect; the state is meaningless without the
application, so there's no reason to encode the state so as to be meaningful
to other applications. The next case is something like this but where the data
might be useful outside the application (auditing, reporting, other features).
In that case, ORM is exactly what you need. Your application wants objects,
but the other things that need the data want it in a database. So you
compromise and store it in a database, using an ORM to make the relational
database look like an object store to your application. The third case is an
application that is not particularly interactive (think credit-card processing
network), and you don't need any app-specific state to be preserved. In that
case, raw database access is perfect; if all you are doing is INSERT INTO
transactions VALUES ('jrockway', 'amazon.com', '19.95'), the ORM is just going
to waste your time.

~~~
pointyhat
They exclude transactions because an ORM maintains a stateful copy of the data
on another tier. Once a copy is made of the data, the guarantee that a
transaction can succeed or the data remains correct is no longer valid.

Considering Fowler spent years pushing ORM's, isn't it a little ironic that
his first law, directly from PoEAA is [1] "Don't distribute your objects" yet
an ORM encourages distribution via the Unit of Work pattern and local stateful
copies.

Technically, the only thing that is possible to work for a Object-oriented
database is a shared heap, which comes with its own bag of concurrency
problems.

Relational databases however, have first class concepts within mathematics
such as sets and all operations take place in one place against one true
source always so transactions can be guaranteed.

ORM's are a recent invention and for some of the really big stuff out there,
they just don't cut it.

I'll post some example cases where transactions and OO falls over if anyone is
interested. I've watched enough concurrency and transaction isolation issues
raised from ORMs to be intimately aware of them now.

[1] <http://martinfowler.com/bliki/FirstLaw.html>

------
MartinCron
I don't really need the external validation anymore. If people do or don't
like some of the tools and techniques that I find useful, it doesn't matter.
Their tastes and tolerances and scenarios are often different.

------
roopeshv
+1 for not just writing to ride on the debate for page views and pointing out
the areas of possible discussion.

------
baddox
The assertion is that ORMs are an anti-pattern because it's hopeless to
represent data from a relational db as object in an OO language. Obviously, an
object or document database maps better to OO languages. My question is, what
programming style maps correctly to relational data, other than the obvious
answer of SQL?

~~~
pointyhat
Functional programming maps perfectly. Consider first class sets in a
language.

------
dustingetz
after blogging this, i found a few example ORM systems which may be
interesting to study. I still don't know the answers, but O/R Broker[2] seems
the tightest one and it isn't even really an ORM[3].

[1] [http://stackoverflow.com/questions/1362748/wanted-good-
examp...](http://stackoverflow.com/questions/1362748/wanted-good-examples-of-
scala-database-persistence) [2] <http://code.google.com/p/orbroker/> [3]
<http://code.google.com/p/orbroker/wiki/JoinExample>

~~~
garysieling
It might be instructive to compare an ORM style API for OLTP style databases
vs. OLAP star schemas (<http://en.wikipedia.org/wiki/Star_schema>). At least,
the question of what a conditions API does / mutates in a query may be a very
different answer between the two.

------
jwatte
Most of the time: Yes, traditional ORMs are an anti-pattern. If you think you
want an ORM, consider an ODB or KVS instead (neither of which are relational).

------
perfunctory
what is conditions api?

~~~
perfunctory
why downvote? That's an honest question.

