Struts and DAO pattern. Expensive?

[Vanderlei Silva <va...@hotmail.com>]

Hi all,

I'm right now having to deal with some tough design decisions concerning 
Data Access Objects (DAOs). I know this is really not a direct related 
Struts question, but I also understand that everybody in this list already 
faced this issue while integrating Struts in their model.

I'm not using EJBs but this should really not be an issue, as the DAOs are 
supposed to be reusable in non-EJBs designs as well. What I have is struts 
dealing with controllers, and these controllers dealing with business ojects 
and DAOs. Let's see what I found/have:

- J2EE Pet Store, in their DAO objects, for every new business method, they 
get a new connection from the pool and later release it. This makes the code 
cleaner at the controller side, but VERY repetitive at the DAO side (note 
that they replicate the getConnection,closeConnection, closeResultSet, 
etc... all over the DAOs. It's kind of amazing to see such a replication in 
a reference implementation. It also sounds very, very expensive to get a new 
connection every time. In some cases, a business method makes a call to 
another business method, and they are getting the connection twice for this. 
Imagine a call where the controller needs to talk to 3 DAOs and perform 
about 10 business method calls. They will get and close the connection 10 
times. The connection pool, managed by the application server, will more 
than likely create a bottle neck in this whole thing.

- in my approach, while testing, the controller is responsible for getting a 
new connection and forwarding it (through parameters) to the DAOs. The 
problems with this approach are: the DAOs are not a member of the Business 
objects, but work in parallel with them. Thus, the controller deals with 
both the business objects and the DAOs, and makes all the "control", serving 
also as a bridge, or facade. The advantage of this approach is that 
basically, for every user request, you will have only one connection lookup, 
doesn't matter how many DAOs methods you call from different objects in 
order to full fill the request.

I need to confess I'm lost. The PetStore approach sounds cleaner in some 
sence, but also sounds too repetite in other, and mostly, sounds way to 
expensive (or it isn't?).

How do you see all this?

Regards,

Vanderlei


_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

Re: Struts and DAO pattern. Expensive?

[Jim Richards <gr...@cyber4.org>]

> I need to confess I'm lost. The PetStore approach sounds cleaner in some
> sence, but also sounds too repetite in other, and mostly, sounds way to
> expensive (or it isn't?).

Struts uses a connection pool. So when you do a getConnection() you're
actually pulling one out from a pool of shared connection objects, so
there is no real problem with generating a new connection.

In my application I have manager objects will deal with data beans, and
these managers have methods that all look the same (open connection, select
data, build bean, close up, return). Yes it's a lot of cut and paste. I'd
prefer to have used EJBs but the project size doesn't warrant such expense
(time and effort, not money).

Re: Struts and DAO pattern. Expensive?

[Calvin Yu <cy...@yahoo.com>]

--- Vanderlei Silva <va...@hotmail.com> wrote:
> The 
> problems with this approach are: the DAOs are not a
> member of the Business 
> objects, but work in parallel with them. Thus, the
> controller deals with 
> both the business objects and the DAOs, and makes
> all the "control", serving 
> also as a bridge, or facade.

I'm having trouble seeing the disadvantage here.

Calvin

__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/