Mailing-List: contact user-java-help@ibatis.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user-java@ibatis.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Date: Sun, 22 Jan 2006 22:31:58 -0700
From: Nathan Maves <Nathan.Maves@Sun.COM>
Subject: Re: iBatis usage pattern
In-reply-to: <c593b8750601222057o1a327f57p2798cab03f4cf90c@mail.gmail.com>
Sender: Nathan.Maves@Sun.COM
To: user-java@ibatis.apache.org
Message-id: <EF20126B-A93A-4E51-8AE8-78F6103288E6@sun.com>
MIME-version: 1.0
Content-type: multipart/alternative;
 boundary="Boundary_(ID_HD83Fth3JbpSfdMaolqSqQ)"
References: 
 <BBB07C847BBE5A49B3A849A8DE7E56CFB3B863@ekamailserver.ekalife2000.com>
 <c593b8750601222057o1a327f57p2798cab03f4cf90c@mail.gmail.com>


--Boundary_(ID_HD83Fth3JbpSfdMaolqSqQ)
Content-type: text/plain; format=flowed; delsp=yes; charset=US-ASCII
Content-transfer-encoding: 7BIT

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.
>


--Boundary_(ID_HD83Fth3JbpSfdMaolqSqQ)
Content-type: text/html; charset=ISO-8859-1
Content-transfer-encoding: QUOTED-PRINTABLE

<HTML><BODY style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; =
-khtml-line-break: after-white-space; ">I agree with Jeff,<DIV><BR cl=
ass=3D"khtml-block-placeholder"></DIV><DIV>The whole point of ORM is =
that both can be developed independently.=A0 You might have one class=
 that is represented by multiple tables or the=A0opposite case where =
multiple class are store in one table.</DIV><DIV><BR class=3D"khtml-b=
lock-placeholder"></DIV><DIV>I would suggest, like Jeff,=A0 making su=
re that your domain model is implemented without thought of how the d=
ata is stored.=A0 Then work on the mapping.</DIV><DIV><BR class=3D"kh=
tml-block-placeholder"></DIV><DIV>Nathan<BR><DIV><DIV>On Jan 22, 2006=
, at 9:57 PM, Jeff Butler wrote:</DIV><BR class=3D"Apple-interchange-=
newline"><BLOCKQUOTE type=3D"cite"><DIV>Well I don't think it's exact=
ly the concept of ORM.=A0 ORM normally says that database design isn'=
t as important as object design.=A0 The philosphy with ORM is that th=
e=A0object model rules all decisions, and that the database model sho=
uld be subservient to the=A0object model.=A0 I don't think this is re=
alistic in many enterprise class applications - DBA's usually have ot=
her perfectly valid concerns that can override this simplistic view o=
f database design.=A0 To them the database is much more than just a p=
lace to store our objects - and they are correct in that thinking. </=
DIV> <DIV>=A0</DIV> <DIV>So I would make an object model that matches=
 your problem space.=A0 And realize that this may, or may not, map ea=
sily to a set of database tables.=A0 If there is a close match, then =
maybe Hibertnate is a decent option.=A0 But in my experience there is=
 often a huge mismatch between the object model model and the databas=
e model.=A0 This is where iBATIS shines and leaves the others gasping=
 for breath. </DIV> <DIV>=A0</DIV> <DIV>Lastly, let me say that a goo=
d POJO based domain model is=A0a far far different thing than "a clas=
s for each table".=A0 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. </DIV> <DIV>=
=A0</DIV> <DIV>HTH -</DIV> <DIV>Jeff Butler<BR><BR>=A0</DIV> <DIV><SP=
AN class=3D"gmail_quote">On 1/22/06, <B class=3D"gmail_sendername">Yu=
suf</B> &lt;<A href=3D"mailto:Yusuf@ekalife.co.id">Yusuf@ekalife.co.i=
d</A>&gt; wrote:</SPAN> <BLOCKQUOTE class=3D"gmail_quote" style=3D"PA=
DDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px sol=
id">Hi Jeff,<BR>So let me conclude your explanation:<BR>It is better =
to create a good pojo based domain model (bottom line, a <BR>class fo=
r each table?) rather than using maps for results (except for<BR>thos=
e one-of-a-kind query), and always try to group results to POJOs,<BR>=
using the "group by" and maybe other ibatis' functionalities, but nev=
er <BR>mess with the domain model. Is it correct? If I'm not wrong, t=
his is<BR>also the concept of all those ORM tools like hibernate, jdo=
, and others?<BR><BR>Thanks,<BR>Yusuf.<BR><BR></BLOCKQUOTE></DIV></BL=
OCKQUOTE></DIV><BR></DIV></BODY></HTML>

--Boundary_(ID_HD83Fth3JbpSfdMaolqSqQ)--