struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Hardy <>
Subject Re: S2: Actions/DAO interaction getting messy...
Date Fri, 28 Mar 2008 00:40:32 GMT
Eric D Nielsen on 26/03/08 15:31, wrote:
> Adam Hardy on 26/03/08 00:28:43
>> Eric D Nielsen on 25/03/08 14:29, wrote:
>>> Its a Struts2/Spring2/JPA(Hibernate) based project. I'm using a slightly
>>> modified version of the Generic DAO pattern shown in the Java persistence
>>> with Hibernate book and/or the IBM ThoughtWorks very similar example.
>>> (Modified to allow Spring Based Injection of the JPA EntityManger, while
>>> falling back to a native Hibernate session inside the DAOs to allow a few
>>> more optimizations).
>>> So its basically
>>> Business Objects (POJOs) <---1:1---> DAOs
>>> which is a relatively normal pattern I beleive.
>> Is it normal with that Generic DAO pattern to name the DAOs 'services'? In the
>> Domain-Driven-Design paradigm that I generally follow, the services are objects
>> which carry out operations that you don't want to specifically assign to one
>> domain object.
> I'm willing to admit a LOT of confusion about DAOs v (Services | Managers) v
> business logic on POJOs.  I will say that my Actions are taking things named
> "services" but typed as DAOs since I thought I would eventually migrate towards
> this extra tier, but have let to really understand what belongs there.  I think
> a large part of my confusion comes from most examples I've seen where just
> about 100% of the method in the vast majority of service classes are proxied
> calls from the DAO.  With only 1-2 methods added to a small percentage of the
> services.  However we are getting quite far afield for Struts matters here.....
> I'd be very happy to receive further enlightenment, but if its better to move
> this part of the discussion elswhere, please let me know...

I guess you want the Spring design paradigm. It's relatively straight-forward 
although you're right - in alot of cases, the managers just wrap the dao calls 
with no added functionality.

>>> just use POJOs there. I believe this approach would work with the
>>> Model-Driven idea, but it feels a little odd to me to mark up the domain
>>> object with HTTP-specific details....
>> Yes it would do, but what do you mean by 'mark up the domain object with
>> HTTP-specific details'? I don't think you have to touch the domain objects to
>> code the re-construction of your incoming Bug POJO.
> Yay! Back to Struts matters...   I haven't written any type converters yet, but
> from the examples I'd been seeing I thought you had to add a @TypeConversion
> annotation to accessors that wanted custom type conversion.
> So if I was using Model Driven, would this mean putting these annotation on the
> model.  (much like the Vistor pattern for Validation)

You don't have to use annotations if you don't want to. You can use property 
files instead.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message