1) Maps classes to tables, and columns to fields.
2) Must support Object Identity
3) Generates SQL
1) Maps objects (not necessarily a custom type, or even the same type) to statements
2) Generally does not support object identity (would be hard to do)
3) Allows complete hand coding of real SQL, with full support for nearly all RDBMS features
Irrelevant. DAO is an abstraction pattern. It serves a different design purpose entirely.
On 11/4/05, Abdullah Kauchali <[EMAIL PROTECTED]> wrote:
So, iBatis is /not/ an ORM.
What makes Hibernate an ORM and iBatis not?
or a corollary:
What makes iBatis a DAO implementation and Hiberate not? (Is this a
valid question, to
What are the /decisive/ qualities of each (viz. DAO vs ORM) that
classify them appropriately?
I am looking for the mosst important /distinguishing/ (different)
characteristics of each approach
so that when I now see a myriad of tools presented to me, I can say "ah,
but this one does it
like this, so it /leans/ towards an ORM approach" ...