ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Larry Meadors <larry.mead...@gmail.com>
Subject Re: Reload Lazy Objects
Date Wed, 29 Jun 2005 17:26:04 GMT
Heh, after sending it, I thouhght "Yuk, what a crappy idea" and
smacked m'self on the forehead for suggesting it. That is what i get
for coding in C#.

My general pattern in Java is to make my "domain objects" very
lightweight - more like simple data transfer objects, with no
awareness of the service or dao layers. That IMO, is a good design:
Simple and easy to test.

I avoid putting them into session or application scope, and cache them
in the dao layer instead. In my case, I am using struts. so what that
means is that the action calls the service to get domain objects, and
puts them into an action form (for input) or request scope (for output
only). My action forms do the translation from the web types (i.e.,
strings) to the domain object types (i.e., dates, numbers, etc). On a
form submission, the action takes them from the action form, and
passes them back into the service layer.

So, I avoid the issue you are talking about, because the user object
in my case would not last longer than the life of the request except
for in the cache that I let iBATIS manage.

Make sense?


On 6/29/05, Mike Fotiou <Mike.Fotiou@pwgsc.gc.ca> wrote:
> Thanks for the response.
> That is an interesting idea.  I haven't played much with the caching mechanism.  I'll
give it a try.  One unrelated question - do lazy-loaded objects check the cache before going
to the db?
> At first, I didn't really want the domain-service interaction - I guess I was thinking
about the "client" (a servlet in this case) using domain objects as inputs into the service
layer and outputs to the presentation layer (JSPs), but I don't see why the domain object
can't have a reference to a service object.  I'm using Spring's injection mechanism to assign
the DAO to the service object, so I could just have the User domain object get a reference
to the service object using a call to the bean factory, which is available as a singleton
> I'm wondering though, why not just add the create/update/addRole/RemoveRole....etc method
to the domain object, inject the DAO into the domain object (or grab the DAO from the factory
singleton in the constructor) and do away with the service layer altogether.
> It seems that sometimes design comes down to splitting hairs...
> -----Original Message-----
> From: Larry Meadors [mailto:larry.meadors@gmail.com]
> Sent: Wednesday, June 29, 2005 12:55 PM
> To: user-java@ibatis.apache.org
> Subject: Re: Reload Lazy Objects
> Could you just have your user object delegate the retrieval of the
> list to the service object (instead of storing it internally) and rely
> on caching instead of lazy loading?
> If an update occurs, the cache gets flushed, and the next call to get
> the list gets fresh data.
> Larry
> On 6/29/05, Mike Fotiou <Mike.Fotiou@pwgsc.gc.ca> wrote:
> >
> > Is there any way in IBATIS to mark an object that was lazy-loaded as
> > "unloaded" so that the object will be reloaded again?  I'm thinking about
> > the following scenario:
> >
> >
> > Domain Objects:
> >
> > User contains Role objects (a List)
> >
> > Sevice Object:
> >
> > UserService.removeUserRole(User u, String roleCode);
> >
> > DAO Object:
> >
> > UserDAO.removeUserRole()....
> >
> >
> > The service object now has to manage the User object's List of roles.
> > Ideally, this List would be immutable, but otherwise the service object has
> > to iterate through the List and remove the appropriate Role object.  I could
> > add a removeRole() method on the User object, but that is a little
> > confusing, as there is a removeUserRole on the ServiceObject.  I do not want
> > to allow the domain objects access to the DAO layer, that's the reason for
> > the service layer.  I'm considering scrapping the service layer altogether
> > in favour of heavy-weight domain objects that can manage their own
> > collections easily.
> >
> > Any ideas?

View raw message