I agree with Jeff,

The whole point of ORM is that both can be developed independently.  You might have one class that is represented by multiple tables or the opposite case where multiple class are store in one table.

I would suggest, like Jeff,  making sure that your domain model is implemented without thought of how the data is stored.  Then work on the mapping.

Nathan
On Jan 22, 2006, at 9:57 PM, Jeff Butler wrote:

Well I don't think it's exactly the concept of ORM.  ORM normally says that database design isn't as important as object design.  The philosphy with ORM is that the object model rules all decisions, and that the database model should be subservient to the object model.  I don't think this is realistic in many enterprise class applications - DBA's usually have other perfectly valid concerns that can override this simplistic view of database design.  To them the database is much more than just a place to store our objects - and they are correct in that thinking.
 
So I would make an object model that matches your problem space.  And realize that this may, or may not, map easily to a set of database tables.  If there is a close match, then maybe Hibertnate is a decent option.  But in my experience there is often a huge mismatch between the object model model and the database model.  This is where iBATIS shines and leaves the others gasping for breath.
 
Lastly, let me say that a good POJO based domain model is a far far different thing than "a class for each table".  What I meant was that it is likely that many of the persistence methods for your domain objects can likely be mapped fairly easily to DAO methods implemented in iBATIS.
 
HTH -
Jeff Butler

 
On 1/22/06, Yusuf <[EMAIL PROTECTED]> wrote:
Hi Jeff,
So let me conclude your explanation:
It is better to create a good pojo based domain model (bottom line, a
class for each table?) rather than using maps for results (except for
those one-of-a-kind query), and always try to group results to POJOs,
using the "group by" and maybe other ibatis' functionalities, but never
mess with the domain model. Is it correct? If I'm not wrong, this is
also the concept of all those ORM tools like hibernate, jdo, and others?

Thanks,
Yusuf.


Reply via email to