Re: [OT] DAO Pattern in Struts
Whats about a thread local variable to store the connection instead of as instance variable ? On 8/24/05, Gareth Evans [EMAIL PROTECTED] wrote: Hi Paul, How about using a DBCP, that way the connections are always there, a getting a connection each time you need to do a unit of work becomes less of an overhead. With dbcp you can create your connection by using an xml file usually named 'something.jocl', drop this into you classpath and load a connection like you normally would, the url for the connection being 'jdbc:apache:commons:dbcp:/something' Take a look at the jocl example http://cvs.apache.org/viewcvs/jakarta-commons/dbcp/doc/ This allows an easy to create, easy to change database configuration, using a connection pool. Regards, Gareth Paul Benedict wrote: Guys, This is off-topic but I need your help. There are some good programmers here and I would like to receive some advice back. I am sure there's a simple answer to it. My Struts app is a multitier app (Web - Business - DAO) and it uses Jakarta Commons DbUtils for the DAO layer. My DAO methods are the typical get connection,execute,close connection pattern. Well, suddenly my DAO methods are complex enough that I can call my publically defined methods as helpers, which leads to all sorts of problems. That would opening a connection per call to a sibling method! What should be done here? I thought of moving the ownership of the connection from the method to the instance level. Is this appropriate? At least I could get sharing of a connection. But some business layers call multiple different DAO objects and it makes even more sense to share a connection across all DAO objects. Would this be better? I think so, but I don't know how to model it. Please, any help! It is holding up my design. Thanks, Paul __ Yahoo! Mail Stay connected, organized, and protected. Take the tour: http://tour.mail.yahoo.com/mailtour.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Gareth Evans MSoft eSolutions Limited Technology Centre Inward Way Rossmore Business Park Ellesmere Port Cheshire CH65 3EN -- Tel:+44 (0)870 0100 704 Fax:+44 (0)870 9010 705 E-Mail: [EMAIL PROTECTED] Web:www.msoft.co.uk -- Terms: Please note that any prices quoted within this e-mail are subject to VAT. All program details and code described in this e-mail are subject to copyright (c) of MSoft eSolutions Limited and remain the intellectual property of MSoft eSolutions Limited. Any proposal or pricing information contained within this e-mail are subject to MSoft eSolutions' Terms and Conditions -- Disclaimer: This message is intended only for use of the addressee. If this message was sent to you in error, please notify the sender and delete this message. MSoft eSolutions Limited cannot accept responsibility for viruses, so please scan attachments. Views expressed in this message do not necessarily reflect those of MSoft eSolutions Limited who will not necessarily be bound by its contents. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- -- Rokibul Islam Khan Software Developer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] DAO Pattern in Struts
Larry Meadors wrote: You can (and should) use the DAO pattern with Hibernate, too. So true, plus a good DAO interface can decouple your database access implementation and the rest of your app, so that you can switch from hibernate to ibatis or plain jdbc or whatever without having to make code changes to anything that uses DB connectivity. M - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] DAO Pattern in Struts
EXACTLY! :-D I think Paul and I mis-communicated on the point of the iBATIS DAO earlier. It is something very different from iBATIS SQL Maps. One of the key principles of Object-Oriented programming is encapsulation – the separation of an implementation and its public interface. The DAO pattern is one more tool that allows you to do that in your applications. By separating the data access details from the data access API, we are able to provide a homogeneous set of interfaces over heterogeneous data access mechanisms. An application can access data from multiple databases, each with a different underlying API using a single consistent data access API. Interestingly, the JDBC API is another application of the DAO pattern. In that realm, you have a set of interfaces, and database vendors implement them in a way that makes it possible to use them interchangeably – for the most part. In a few cases, where vendors feel that the interfaces do not provide the capability to do things that they want to do, they work outside the interface. This pattern is one of the things that make tools like iBATIS SQL maps and Hibernate possible. Because nearly all database vendors implement the JDBC APIs reasonably accurately, tools can be written that operate against those interfaces instead of the underlying implementations, and for the most part, those tools will work with any vendor's implementation. This is one of the goals of the iBATIS DAO – to help you provide a set of interfaces to your applications that hide the underlying implementation of the data access. So, if you have a Hibernate based application that uses the DAO pattern, you can replace that with a SQL Map based implementation, or a JDBC based implementation without having to rewrite the entire application. Instead, all that needs to be changed is the implementations of the interfaces that the application is using. As long as the DAO interface is implemented correctly, the application will continue to function as expected. Larry On 8/24/05, Emmanouil Batsis [EMAIL PROTECTED] wrote: Larry Meadors wrote: You can (and should) use the DAO pattern with Hibernate, too. So true, plus a good DAO interface can decouple your database access implementation and the rest of your app, so that you can switch from hibernate to ibatis or plain jdbc or whatever without having to make code changes to anything that uses DB connectivity. M - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[OT] DAO Pattern in Struts
Guys, This is off-topic but I need your help. There are some good programmers here and I would like to receive some advice back. I am sure there's a simple answer to it. My Struts app is a multitier app (Web - Business - DAO) and it uses Jakarta Commons DbUtils for the DAO layer. My DAO methods are the typical get connection,execute,close connection pattern. Well, suddenly my DAO methods are complex enough that I can call my publically defined methods as helpers, which leads to all sorts of problems. That would opening a connection per call to a sibling method! What should be done here? I thought of moving the ownership of the connection from the method to the instance level. Is this appropriate? At least I could get sharing of a connection. But some business layers call multiple different DAO objects and it makes even more sense to share a connection across all DAO objects. Would this be better? I think so, but I don't know how to model it. Please, any help! It is holding up my design. Thanks, Paul __ Yahoo! Mail Stay connected, organized, and protected. Take the tour: http://tour.mail.yahoo.com/mailtour.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] DAO Pattern in Struts
Have you looked at using something like the iBATIS DAO? I think it could save you alot of pain. One thing to watch out for is thread safety - putting a connection on an instance (especially a shared instance) is pretty risky, especially when you start thinking about transactions and the like...that kind of thing is really better handled at the thread level (which is what iBATIS does). Larry On 8/23/05, Paul Benedict [EMAIL PROTECTED] wrote: Guys, This is off-topic but I need your help. There are some good programmers here and I would like to receive some advice back. I am sure there's a simple answer to it. My Struts app is a multitier app (Web - Business - DAO) and it uses Jakarta Commons DbUtils for the DAO layer. My DAO methods are the typical get connection,execute,close connection pattern. Well, suddenly my DAO methods are complex enough that I can call my publically defined methods as helpers, which leads to all sorts of problems. That would opening a connection per call to a sibling method! What should be done here? I thought of moving the ownership of the connection from the method to the instance level. Is this appropriate? At least I could get sharing of a connection. But some business layers call multiple different DAO objects and it makes even more sense to share a connection across all DAO objects. Would this be better? I think so, but I don't know how to model it. Please, any help! It is holding up my design. Thanks, Paul __ Yahoo! Mail Stay connected, organized, and protected. Take the tour: http://tour.mail.yahoo.com/mailtour.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] DAO Pattern in Struts
Not sure if this is really much help because I'm sure you've thought of this, but I mirror many or all of my DB DAO methods with methods that take the Connection as a parameter . . . In the primary method, they obtain their own Connections, but in the secondary method, they use whatever Connection is passed as a parameter. Then I have an adapter between the business manager and the DAOs which obtains a Connection (and for example turns off autocommit), passes it to many DAO methods, and then releases the Connection (after turning autocommit back on). If you are using Connection pooling though, the cost still may be very low and not worth the trouble, as you are not really opening any Connections for each DAO call -- the pool keeps them open all the time. When you get a Connection, it comes from a cache. When you invoke close on the Connection, you are really invoking close on an adapter which releases the Connection back to the cache . . . (But sometimes you need to share a Connection for another reason besides optimization.) Someone correct me if I'm wrong. Hope that helps, as I'm not familiar with the Jakarta DAO stuff. Erik -Original Message- From: Paul Benedict [EMAIL PROTECTED] Sent: Aug 23, 2005 6:35 PM To: user@struts.apache.org Subject: [OT] DAO Pattern in Struts Guys, This is off-topic but I need your help. There are some good programmers here and I would like to receive some advice back. I am sure there's a simple answer to it. My Struts app is a multitier app (Web - Business - DAO) and it uses Jakarta Commons DbUtils for the DAO layer. My DAO methods are the typical get connection,execute,close connection pattern. Well, suddenly my DAO methods are complex enough that I can call my publically defined methods as helpers, which leads to all sorts of problems. That would opening a connection per call to a sibling method! What should be done here? I thought of moving the ownership of the connection from the method to the instance level. Is this appropriate? At least I could get sharing of a connection. But some business layers call multiple different DAO objects and it makes even more sense to share a connection across all DAO objects. Would this be better? I think so, but I don't know how to model it. Please, any help! It is holding up my design. Thanks, Paul __ Yahoo! Mail Stay connected, organized, and protected. Take the tour: http://tour.mail.yahoo.com/mailtour.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] DAO Pattern in Struts
Erik, Oh, I have worked on a project where that was the pattern I designed for myself!! One accepted a connection for transactions, the other for self-contained singleton executions. Yup, it's a great pattern. You raise an interesting point. I never thought about using a middle-man between my business tier and DAO. I'll have to think about that. And yes, I do use connection pooling -- good point! I guess there is not a performance gain in keeping the connection around at the instance level. Perhaps I am being scrupulous and trying to save time with the pool code, but that's ridiculous. It's better to put it back in the pool because at the millisecond level, many more threads could be using it in between my thread. And, I like the IBATIS idea described by Larry... but sorry, I love Hibernate :-) I don't use it yet, but I am on board whenever I get to use it. Thanks! Paul Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] DAO Pattern in Struts
You can (and should) use the DAO pattern with Hibernate, too. The iBATIS DAO even has built-in support for hibernate (of course, it has support for sql maps, too). Larry On 8/23/05, Paul Benedict [EMAIL PROTECTED] wrote: Erik, Oh, I have worked on a project where that was the pattern I designed for myself!! One accepted a connection for transactions, the other for self-contained singleton executions. Yup, it's a great pattern. You raise an interesting point. I never thought about using a middle-man between my business tier and DAO. I'll have to think about that. And yes, I do use connection pooling -- good point! I guess there is not a performance gain in keeping the connection around at the instance level. Perhaps I am being scrupulous and trying to save time with the pool code, but that's ridiculous. It's better to put it back in the pool because at the millisecond level, many more threads could be using it in between my thread. And, I like the IBATIS idea described by Larry... but sorry, I love Hibernate :-) I don't use it yet, but I am on board whenever I get to use it. Thanks! Paul Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
