Re: ORMs comparisons/complaints.
On 12/22/2013 4:26 PM, Marcel M?ller wrote:
On 22.12.13 20.05, Daniel Pitts wrote:
I've been doing some thinking about my experiences with various ORMs,
both positive and negative. I find that I often stretch systems to there
limits, and end up doing a lot of meta-programming to solve problems
that I've always felt should have been solved by the core libraries.
Mostly to follow DRY and KISS principals in the core business code.
First of all you need to mention what ORMs are designed for. They are
intended to make SQL databases suitable for OO programming style and/or
non-relational data models. At the end OO expressions are turned into
SQL and then to an execution plan.
From that you can see that there is exactly one thing superfluous in
this scenario: SQL. It is the bottleneck where all expressions must fit
to. But it does not add any functionality, quite the contrary. It is
just a emulation level for compatibility, like a SATA adapter enables a
SATA drive to be used with an IDE port.
You see, I am not really a friend of ORM. If a relational data model
does not fit your needs, you first should consider to use a non
relational database, rather than to normalize the data model to fit into
a relational DB, and use an ORM to hide that from the application layer.
Yes and no.
If you could get non-relational databases with same transactional
support, same tools, same vendor support etc..
And if all access to the database is OO based.
Then that would be obvious.
But the non-relational databases has not reached the same maturity level
(as a summary term for the above) as relational databases.
And it is common to have the same databases used by modern OO based
software also to be used by non-OO legacy software (like 20 year
old COBOL programs).
ORMs are known to slow things down. I don't think that this is true in
general. But the ORM layer makes some trivial looking expressions
amazingly complex. So it is not that easy for the programmer to estimate
the complexity of a code block, without knowledge about the entire ORM
layer and the base data model in SQL. In fact I have redesigned many
code parts because of this.
Oh - I have seen my share of that.
It should be mandatory for developers writing code using ORM to do some
testing with the logging of actual SQL statements executed turned on. It
reveals what is going on without having to know so much about the inside
of the ORM.
Of course, if you are stuck with an SQL DB for some reason and you need
to adapt to an OO application layer ORM might be a choice. But if the
data model in the DB is not intended for ORM usage, you won't get happy,
because there are almost always properties of the data model that are
not correctly modeled in SQL.
It seems as if very large parts of the Java, .NET and Ruby worlds
are able to make it work.
Arne