ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Fotiou" <Mike.Fot...@pwgsc.gc.ca>
Subject RE: Reload Lazy Objects
Date Wed, 29 Jun 2005 18:30:23 GMT
Makes good sense...

The approach I took on the last project (which was not very good) and which involved Struts
was to use "intelligent", heavy-weight domain objects.  We did not have a DAO layer, instead
the domain objects talked to the database directly.  Not separating the data access into another
layer was a horrible design, very hard to test, and made for massive domain objects.  We were
using DynaActionForms (they are also horrible), so the action was responsible for translating
the domain object to/from the action form.  The domain object was cached in the session between
requests.

In your design, which I tend to agree with, how would you show a list of roles for a user?
 Imagine a "user" screen, which displays fields for the user info, plus lists representing
the 1:M relationships, below the fields.  Each row would have an edit/remove button, etc...
Would you make a second call to your DAO to get the user details and then assign it to a property
of the action form eg. getUserRoles(userId)?  

One other question - is the IBATIS cache last the lifetime of the JVM - i.e. would all request
threads access the same cache?  I assume the result maps are somehow identified by the parameters
passed into the statement, rather than just the statement name itself?

-----Original Message-----
From: Larry Meadors [mailto:larry.meadors@gmail.com]
Sent: Wednesday, June 29, 2005 1:26 PM
To: Mike Fotiou; user-java@ibatis.apache.org
Subject: Re: Reload Lazy Objects


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?

Larry


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

Mime
View raw message