Re: ORMs comparisons/complaints.
On 1/2/2014 6:36 AM, Silvio wrote:
On 01/02/2014 04:19 AM, Arne Vajh?j wrote:
On 12/30/2013 8:38 AM, Silvio wrote:
Apart
from the fact that I think that this is a bad approach on its own, to
constrain memory usage objects need to be put to sleep by default and be
resurrected only when they are accessed.
That is how persistence works. The data are on disk and when a program
needs them they are read from disk to memory.
This makes the approach even
more blurred and needlessly complex, bringing stuff like caching and
managing/synchronizing duplicate object instances across concurrently
running program instances into the picture.
But that is not in any way ORM specific.
Plain JDBC will have the same potential issues with caching.
In theory the ORM approach does not need more caching than a RDBMS
driven approach. In practice this is not the case.
????
Some ORM's come without what at least in the Java world is known
as level 2 cache (cache of data outside of ongoing transaction).
But for those with level 2 cache, then I have never seen one
where it could not be disabled.
If you don't want it, then just turn it of.
The number of cases
where caching outside of the RDBMS is actually needed is very limited
and I rarely use any form of data caching.
????
Use of cache is essential for achieving good performance for many many
types of application no matter language, database or database access
technology.
Without exception all the ORM systems I worked on relied heavily on
caching or the would not be practically usable.
I don't know what ORM's you have worked with.
But the ORM's create the same SQL as handwritten SQL, so there are
no more and no less need for caching.
Furthermore among some of the most popular ORM's then level 2 cache is
either disabled by default (Hibernate) or not existing (EF).
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.
????
Joins is a core feature of an ORM.
You can do joins easily but that is not the big problem. The core
problem is that joins create new views on the underlying data that do
not match with the entity classes that match its underlying tables. To
represent the data from a join properly you would need a new class and
then you get into one of the biggest culprits with ORM: aliased data and
cache redundancy.
????
Any decent ORM just do the joins, load the data and no aliased data
(beyond where required due to data actually being the same also in the
database).
Arne