ibatis-user-cs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nguyen, Tom" <Tom.Ngu...@rels.info>
Subject RE: Persisting Object Graph
Date Mon, 25 Sep 2006 16:59:06 GMT
Correction: Rels.Business.Blog.Insert *= Rels.Business.Blog.Delete

In response to:
> to persist all the related objects. It will be much easier if we have 
> similar construct describing object relationship
>
> for insert, update and delete as in "select" clause in ParameterMap.

I feel that the DataMapper is great at what it does already.  It only
responsibility is to implement the DataMapper Pattern.  There's no need
to add new constructs into the DataMapper sql config xml.  Maybe the new
Object Persistence construct should be something similar to the iBatis
DataAccess (in separate xml).  This is why I choose to use (HasOne or
HasMany) attributes and CascadeMode enumeration to represent object
relation in my implementation.

Regards,
 
Tom Nguyen
Sr. Developer
tom.nguyen@rels.info

-----Original Message-----
From: Nguyen, Tom [mailto:Tom.Nguyen@rels.info] 
Sent: Monday, September 25, 2006 11:43 AM
To: user-cs@ibatis.apache.org
Subject: RE: Persisting Object Graph

I was actually doing exactly this in my demo project that I posted some
months ago.  See - ObjectPersister.

http://www.noogen.net/download/free/Blogs.zip

FYI:

>From my presentation feedback, I found that it was hard for (.Net)
Developers to get head around the (java) DAO Pattern.  It was also too
much work to generate and maintain these DAO.  My new implementation
relies on the generated CRUD DataMapper statements to be the object's
full type name. 

Example:  I would have mapped statement like this

Rels.Business.Blog.Fill
Rels.Business.Blog.Create
Rels.Business.Blog.Retrieve
Rels.Business.Blog.Update
Rels.Business.Blog.Insert

>From experience, we can say that roughly 90%+ of our work revolves
around CRUD statements.  For custom statement, I just go directly to
ObjectPersister.DataMapper.Map.QueryFor...(customstatementname, ...).

It's basically writing a new DataAccess method instead of using iBatis
which involves DAO.

I'm working on some sample of the new code.  I will post to the list
shortly if anyone interested.

Regards,
 
Tom Nguyen
Sr. Developer
tom.nguyen@rels.info

-----Original Message-----
From: Peter Mills [mailto:development@peter.mills.to] 
Sent: Monday, September 25, 2006 11:18 AM
To: user-cs@ibatis.apache.org
Subject: Re: Persisting Object Graph

I would love to hear more about your solutions, Brian. I plan on 
implementing similar functionality.

Cheers,

Peter

Choi, Brian wrote:

> Hi all. Anybody implemented Object Graph Persistence using IBatis?
>
> It seems like there is only loading support via Lazy Load. (Java 
> version has join fetch).
>
> It will be great if someone can share their experience or best
practice.
>
> Currently I am using external xml or custom attribute so that I can 
> use that info
>
> to persist all the related objects. It will be much easier if we have 
> similar construct describing object relationship
>
> for insert, update and delete as in "select" clause in ParameterMap.
>
> Brian Choi
>

************************************************************************
************
This e-mail message and any files transmitted herewith, are intended
solely for the
use of the individual(s) addressed and may contain confidential,
proprietary or 
privileged information.  If you are not the addressee indicated in this
message 
(or responsible for delivery of this message to such person) you may not
review, 
use, disclose or distribute this message or any files transmitted
herewith.  If you 
receive this message in error, please contact the sender by reply e-mail
and delete
this message and all copies of it from your system.
************************************************************************
************
************************************************************************************
This e-mail message and any files transmitted herewith, are intended solely for the
use of the individual(s) addressed and may contain confidential, proprietary or 
privileged information.  If you are not the addressee indicated in this message 
(or responsible for delivery of this message to such person) you may not review, 
use, disclose or distribute this message or any files transmitted herewith.  If you 
receive this message in error, please contact the sender by reply e-mail and delete
this message and all copies of it from your system.
************************************************************************************

Mime
View raw message