ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yusuf" <Yu...@ekalife.co.id>
Subject RE: iBatis usage pattern
Date Mon, 23 Jan 2006 06:12:28 GMT
Hi All,
I think I'm starting to understand now, well I guess I'm off to
designing a good domain model before trying to do something else :)

And for what it's worth, I think iBatis is still the best out there for
this kind of tool.

Thank You,
Yusuf.

-----Original Message-----
From: Nathan Maves [mailto:Nathan.Maves@Sun.COM]
Sent: Monday, January 23, 2006 12:32 PM
To: user-java@ibatis.apache.org
Subject: Re: iBatis usage pattern


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 <Yusuf@ekalife.co.id> 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.
>



Mime
View raw message