RE: Struts and DAO pattern. Expensive?
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/
Re: Struts and DAO pattern. Expensive?
--- Vanderlei Silva <[EMAIL PROTECTED]> 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/
Re: Struts and DAO pattern. Expensive?
>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). Jim, Instead of Struts connection pool management, I'm using WebLogic's. But that (hopefully) wouldn't cause a big difference. I guess I got the design approach that you used. The managers (also called controllers) are the ones responsible for all the business logic, while also talking to the DAO (your data beans). But then, aren't we kind of breaking the idea of autonomous objects here? I mean, if you have a User object, this user should know how to save himself, how to retrieve it's own address, how to combine first and last name to return a full name (bad example of business logic this one, but will do for now!), etc. I saw some time ago, a big system where they had business objects, DAOs for those business objects, and managers. Basically, the way they did it, the managers had all the business logic, creating business objects, DAOs whenever necessary. The business objects had no logic whatsoever, and where nothing more than simple value objects (or model objects if you wish). It's one way to do it, it's just that I really feel like I'm doing a sin. :) Regards, Vanderlei _ Get your FREE download of MSN Explorer at http://explorer.msn.com
Re: Struts and DAO pattern. Expensive?
> 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?
Title: RE: Struts and DAO pattern. Expensive? 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
