Why not have your Managers create a connection as well
as taking in a connection?
Calvin
--- Shunhui Zhu <[EMAIL PROTECTED]> wrote:
> That opens up lots of questions I also have, I'm
> sure many of you have
> some
> solutions to these:
>
> (1)I went through a similar exercise, I first
> followed the Petstore
> example,
> to have a getConnection() method in my DAOs (well, I
> have BaseDAO, so at
> least the code is not duplicated). The good thing,
> as pointed out, is
> that the
> business object plus the DAO become self-contained.
> The bad thing is
> there
> are too many connections open. At first I thought
> that since I'm using
> connection pool, getting a connection is not too
> expensive. But I
> quickly found
> out there are a huge number of connections open at
> anytime for a not so
> complicated object hierarchy. So now all my save,
> delete methods now
> take
> a connection parameter (which is also for
> transaction purposes).
>
> But this leads to another problem
>
> (2) I follow the convention that all my business
> objects have: Foo,
> FooDAO,
> FooManager (and even FooFactory). FooManager
> contains the finder methods
> (getByID,
> getAll, etc.), now these also take a connection as a
> parameter. But I
> also made
> a decision to hold id references rather than object
> reference in my
> business objects
> (to avoid huge object hierarchy loading), and only
> lazily load a
> dependent object
> when getFooChild() is called (which has no
> parameter, as usual), which
> calls the
> manager classes, but now there doesn't seem to be a
> good place to get
> the connection
> to pass to getByID.
>
> What is a better way? anything should be done
> differently with or
> without entity EJBs?
>
> Any comments are appreciated.
>
> Thanks.
>
> Shunhui
>
> -----Original Message-----
> From: Vanderlei Silva
> [mailto:[EMAIL PROTECTED]]
> Sent: Monday, May 07, 2001 6:00 PM
> To: [EMAIL PROTECTED]
> Subject: Struts and DAO pattern. Expensive?
>
>
> 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
>
>
__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/
