Re: ORMs comparisons/complaints.
On 12/30/2013 12:36 PM, Daniel Pitts wrote:
On 12/30/13 5:38 AM, Silvio wrote:
[snip]
To make things worse almost no system only needs single object
instances. Almost any practical system needs counts, averages etc. which
could be done with a query on an RDBMS or by traversing object instances
IF THEY WHERE REAL INSTANCES. Since doing the latter with an ORM would
require resurrecting enormous amounts of instances for practical reasons
you have to pour water into the wine and do atypical stuff like joins
and aggregate queries through the ORM. I know they CAN do this but that
is no more than a wart on such systems since they contradict the primary
goal of an ORM. This is also the area where ORMs failed in the projects
I talked about. It's not that the ORM can not do it, it just can not do
it sufficiently well even with help from the most experienced experts we
could find.
This is a good point, and it was something niggling in subconscious.
This is where I've always struggled with ORMs, but I never consciously
acknowledged that the difficulty was in utilizing the power of the "R"
in The ORM.
I still think the best approach for most systems is to design a separate
and independent data store that covers the problem domain which is
completely isolated from the systems that implement data extractions,
processes and data storage. I do not manually write code to serialize
object instances since I do not serialize them in the first place. Such
a data store can be an RDBMS but if so desired a NoSQL thingy or even a
file system could do well. Using an RDBMS gives the additional advantage
that the data is readily accessible for standard reporting and ETL tools.
This is one approach. I think one of the major "features" of most ORM
implementations is that they attempt to abstract away the actual RDBMS
layer to the point where you feel "dirty" trying to access it in any
meaningful way. This does provide some value in portability, but many
applications rarely need this portability of RDBMS, and more often
benefit from special features of the particular RDBMS chosen.
Plain JDBC code can be written rather portable as well *within* the
area where ORM actually makes sense, so I agree that portability
is not the big argument for ORM.
To me the advantage of using an ORM is simply all the code you
don't have to write.
Regarding getting away from the relational database, then note
that common Java ORM's like JPA implementations and Hibernate
actually allows you to use SQL queries. It is not strongly typed,
but the capability is there.
Arne