Ted Neward describes somesome negative experiences with object-relational mappers (quoted via James Robertson, as Ted's blog seems to be down at the moment).
With object-relational technologies, products begin by flirting with simple mappings: single class to single table, building simple Proxies that do some Lazy Loading, and so on. "Advisers" are sent in to the various project teams that use the initial O-R layer, but before long, those "advisers" are engaging in front-line coding, wrestling with ways to bring object inheritance to the relational database.I think some of the problems with ORMs are due to being too Object, and not enough Relational. It's entirely appropriate -- obvious, even -- that the database should be represented through objects. It is nice if the structure of the database is also represented through objects, hopefully at a fine level of detail. When you create SQL strings, you are hiding the structure in relatively opaque strings. When you have query results that are just lists of lists, or lists of dictionaries, you have lost a lot of information.
So, you want good objects. The problems I see is when you try to represent classes through the ORM, or relatedly when you do modeling and then apply the ORM after. Objects are fine and well, but it's still an RDBMS you are dealing with. Concepts like subclassing just don't make sense. Is-a is not a term you should be thinking about. And when you are using your objects, you shouldn't expect to forget what they really are -- connectors to the database.
I think a good ORM needs to be simple and transparent in the way it deals with the database, so you don't forget what you are dealing with. But I don't think it needs to represent every relational programming concept natively. Just as an object programmer needs to think about relations, a relational programmer needs to think about objects, and the ORM should be the intersection of those two, not the union.
"Objects are fine and well, but it's still an RDBMS you are dealing with."
Unless, of course, it isn't. Part of the appeal of an ORM in my experience is the ability to also transparently persist objects in containers which are not RDBMS's. My current example: a biz app which has two storage mechanisms; one is a relational DB--the kind of thing SQLObject would work perfectly with. But half the data is stored in a third-party container, which provides SQL for reading, but a proprietary API for writing, which models objects completely differently.
"...And when you are using your objects, you shouldn't expect to forget what they really are -- connectors to the database."
Sorry, I don't buy it. Abstraction is forgetfulness, IMO.# Robert Brewer
I'm with Ian here, the nail has been firmly hit on the head. Every time I've come across object relational mapping it's OO programmers trying to persist an object model in a database. Its all in the compromise, and using the strengths of both approaches rather than sticking only to one.
V.S. Babu had an interesting point;
Which I followed up;
ORM tools have two different jobs depending on what comes first in the design: with objects first there is persistence, portable to different datastores because the objects remain the same and as transparent as possible because one only needs to write objects and get them back; with database first there is a struggle to perform database operations and present data as objects in the context of a certain program: the transparency and portability are turned around (any program can use the OO view of a certain database provided by the tool and all database clients are the same).
# Lorenzo Gatti
I partly agree with you. But after the class generation, then those classes are saved in the persistance layer and the mapping files are also generated.After that you can perform the operation on xml. ORM is very powerful tool because it provide database independence. If you have any objection, you can mail me at email@example.com
Adeel Hussain# Adeel Hussain