Re: ORMs comparisons/complaints.
On 12/30/2013 8:38 AM, Silvio wrote:
On 12/30/2013 05:27 AM, Arne Vajh?j wrote:
On 12/23/2013 7:25 AM, Silvio wrote:
Most places they are actually able to get ORM working.
I am not quite sure that I can follow you.
If you want OO for the code and you want the relational database,
then you must do a mapping between the two.
You can either hand write a lot of code or use an ORM.
Typical using an ORM is faster because it means less code.
You may not be able to use ORM 100%, but then use it 90% and
hand write code for the remaining 10%.
ORMs are good at what they where invented for: serializing an object and
resurrecting it at a later point in time.
Storing objects in a relational database via ORM is very different
from serialization (for non-trivial usage).
A serialization stores everything in a sequential stream of data.
Storing objects in a relational database via ORM store the stuff
not already stored in different tables.
Using a document store have some similarities with serialization.
That means you have to design
your system and its underlying data as a collection of objects with
(encapsulated) member data. Using that approach the lifetime of an
object instance must be able to extend the actual running span of the
program. That requires serialization/resurrection by definition.
It requires the ability to save and load data.
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.
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.
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.
Aggregate functions are not very ORM'ish.
But if they are used much in the transactional work that ORM
is intended, then something is wrong in the first place.
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
Joins is a core feature of ORM.
And common Java ORM's like JPA implemntations and Hibernate does
aggregate functions exactly like SQL in JPQL and HQL respectively.
I wonder what kind of "experts" you got.