This is a nice pattern, but I do not want my DAO to be responsible for
getting the connection. I need to use them in the web-tier (no EJBs) and
possibly also the middle tier. In each case the DataSource may be obtained
in a different manner and it is not the DAO's responsibility to know how.

mark

-----Original Message-----
From: Pathangi, Rao H. [mailto:[EMAIL PROTECTED]]
Sent: 18 July 2001 15:33
To: '[EMAIL PROTECTED]'
Subject: RE: Where do YOU put JDBC calls?


Mark

To handle this situation, I wrote a base class which has the connection
Object as a protected variable. Lets say you have a method readOrder(String
orderId)..

Write another abstract method getConnection() in your BaseDAO. Use
connection manager or pooling or whatever, but get a connection in this
method and implement it in your DAo that extends the BaseDAo

Now in the method readOrder can read something like this

readOrder(String OrderId)
{
try
{
   Connection con = getConnection(); // Your DAO is now plugged
   // Do something with the connection...       

}
catch{}
finally
{
//close connection, unplug your DAO
}
}


Hope that helps
pathangi r

-----Original Message-----
From: Geddes, Mark (ANTS) [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, July 18, 2001 9:23 AM
To: '[EMAIL PROTECTED]'
Subject: RE: Where do YOU put JDBC calls?


ditto.
I am always reading that the Connection reference should be passed into the
method. After writing a few DAOs in this manner, I found the exception
handling too tedious - I was checking for closed connections both within the
DAO method and also in the calling method. So I usually pass in a DataSource
and ensure that my DAO method obtains and closes the connection. Shoot me
down if you like.

Mark

-----Original Message-----
From: Pathangi, Rao H. [mailto:[EMAIL PROTECTED]]
Sent: 18 July 2001 15:18
To: '[EMAIL PROTECTED]'
Subject: RE: Where do YOU put JDBC calls?


Iam using the DAO(Data Access Object) design pattern for such Data access
situations. DAO is a layer of abstraction that works in conjunction with the
Business Object which is nothing but a container for business data. the
Business Object calls the DAO's business methods. The DAO's Business methods
wrap the JDBC Code for data base interaction. Its been explained clearly on
the J2EE blueprints section.Once you are done writing your DAO's, extend the
DAO into a session bean or use it seperately.
 
regards
pathangi r
 
 -----Original Message-----
From: Ryan Cornia [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, July 18, 2001 8:56 AM
To: [EMAIL PROTECTED]
Subject: Where do YOU put JDBC calls?



I'm wondering what people are considering best practices for JDBC calls?
 
I have been writing beans that wrap a database table, and include functions
"select", "insert", "delete". These functions either load the bean, insert
the bean values in the database, or delete the record from the database. In
all of these functions, I pass in a database connection from the action. (Or
whatever else is calling the bean.)
 
ie- public boolean select(Connection cn1, String primaryKey)
 
How are others doing it? I think this is a good approach, but want to see if
someone has come up with something better.
 
Thanks,
Ryan
 


***************************************************************************
This email message contains confidential information for the above addressee
only.  If you are not the intended addressee you must not disclose or use
the information in any manner whatsoever.

Any opinion or views contained in this email message are those of the
sender, do not represent those of the Company in any way and reliance should
not be placed upon its contents.

Unless otherwise stated this email message is not intended to be
contractually binding.  Where an Agreement exists between our respective
companies and there is conflict between the contents of this email message
and the Agreement then the terms of that Agreement shall prevail.

Abbey National Treasury Services plc. Registered in England. Registered
Office:  Abbey House, Baker Street, London NW1 6XL.  Company Registration
No: 2338548.  Regulated by the SFA
***************************************************************************

Reply via email to