RE: Where do YOU put JDBC calls?
Commercial The folks responsible for the J2EE patterns catalog pages have also published a (much extended) discussion of these patterns in book form. It is ***well*** worth your time and money to acquire and read this! Alur, Deepak, Crupi, John, and Malks, Dan, Core J2EE Patterns: Best Practices and Design Patterns, Prentice Hall, 2001. ISBN# is 0-13-064884-1 /Commercial Craig McClanahan On Thu, 19 Jul 2001, nicolas bonvin wrote: just in case, the link to sun's very-worth-reading J2EE pattern page (Beta) http://developer.java.sun.com/developer/technicalArticles/J2EE/patterns/ follow the J2EE Patterns Catalog link, register, then look for the DataAccessObject Pattern under the Integration Tier Patterns or if you are already a registered member of the Java Developer Connection, go directly to http://developer.java.sun.com/developer/restricted/patterns/DataAccessObject .html cheers, nicolas b. -Original Message- From: Ritter, Steve [mailto:[EMAIL PROTECTED]] Sent: Wednesday, July 18, 2001 6:41 PM To: '[EMAIL PROTECTED]' Subject: RE: Where do YOU put JDBC calls? Ryan, you should really read the J2EE blueprints on DAO. It covers everything you need to know. Search aroun javasoft.com for the blueprints (they are documents, not software). --Steve -Original Message- From: Ryan Cornia [mailto:[EMAIL PROTECTED]] Sent: Wednesday, July 18, 2001 7:36 AM To: [EMAIL PROTECTED] Subject: RE: Where do YOU put JDBC calls? From my understanding then - I would have my Business Object class that wraps the table, lets call it Address. I would have a DAO object that is specific to that Business object for the JDBC calls, lets call it AddressDAO. In Address, I would have loadAddress, DeleteAddress, InsertAddress, all of which would call AddressDAO to do the actual JDBC call? Any simple examples of these two classes that are not EJB's? Is this the route to go if I'm not using EJB's? Thanks, Ryan [EMAIL PROTECTED] 07/18/01 08:17AM 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]] 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
RE: Where do YOU put JDBC calls?
You might want to take a look at Java Data Objects (JDO) specification (http://access1.sun.com/jdo/). The RI has been released. It's also supported in Forte (http://www.sun.com/forte/ffj/resources/articles/transparent.html http://www.sun.com/forte/ffj/resources/articles/jdo.html), and I suspect that Netbeans has or will soon get a JDO module. There is an open source implementation as part of the JBossproject, see http://www.jboss.org/jboss-castor.jspfor details. Using JDO saves you from having to code SQL, but more than that it provides deployment time binding of your classes to the underlying database schema. No more code changeswhen the DBA's change the column names, etc! -Original Message-From: Ryan Cornia [mailto:[EMAIL PROTECTED]]Sent: Thursday, July 19, 2001 00:36To: [EMAIL PROTECTED]Subject: RE: Where do YOU put JDBC calls? From my understanding then - I would have my Business Object class that wraps the table, lets call it Address. I would have a DAO object that is specific to that Business object for the JDBC calls, lets call it AddressDAO. In Address, I would have loadAddress, DeleteAddress, InsertAddress, all of which would call AddressDAO to do the actual JDBC call? Any simple examples of these two classes that are not EJB's? Is this the route to go if I'm not using EJB's? Thanks, Ryan [EMAIL PROTECTED] 07/18/01 08:17AM Iam using the DAO(Data Access Object) design pattern for such Data accesssituations. DAO is a layer of abstraction that works in conjunction with theBusiness Object which is nothing but a container for business data. theBusiness Object calls the DAO's business methods. The DAO's Business methodswrap the JDBC Code for data base interaction. Its been explained clearly onthe J2EE blueprints section.Once you are done writing your DAO's, extend theDAO into a session bean or use it seperately.regardspathangi r-Original Message-From: Ryan Cornia [mailto:[EMAIL PROTECTED]]Sent: Wednesday, July 18, 2001 8:56 AMTo: [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, insertthe bean values in the database, or delete the record from the database. Inall of these functions, I pass in a database connection from the action. (Orwhatever 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 ifsomeone has come up with something better.Thanks,Ryan
RE: Where do YOU put JDBC calls?
just in case, the link to sun's very-worth-reading J2EE pattern page (Beta) http://developer.java.sun.com/developer/technicalArticles/J2EE/patterns/ follow the J2EE Patterns Catalog link, register, then look for the DataAccessObject Pattern under the Integration Tier Patterns or if you are already a registered member of the Java Developer Connection, go directly to http://developer.java.sun.com/developer/restricted/patterns/DataAccessObject .html cheers, nicolas b. -Original Message- From: Ritter, Steve [mailto:[EMAIL PROTECTED]] Sent: Wednesday, July 18, 2001 6:41 PM To: '[EMAIL PROTECTED]' Subject: RE: Where do YOU put JDBC calls? Ryan, you should really read the J2EE blueprints on DAO. It covers everything you need to know. Search aroun javasoft.com for the blueprints (they are documents, not software). --Steve -Original Message- From: Ryan Cornia [mailto:[EMAIL PROTECTED]] Sent: Wednesday, July 18, 2001 7:36 AM To: [EMAIL PROTECTED] Subject: RE: Where do YOU put JDBC calls? From my understanding then - I would have my Business Object class that wraps the table, lets call it Address. I would have a DAO object that is specific to that Business object for the JDBC calls, lets call it AddressDAO. In Address, I would have loadAddress, DeleteAddress, InsertAddress, all of which would call AddressDAO to do the actual JDBC call? Any simple examples of these two classes that are not EJB's? Is this the route to go if I'm not using EJB's? Thanks, Ryan [EMAIL PROTECTED] 07/18/01 08:17AM 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]] 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
Re: Where do YOU put JDBC calls?
Hello Ryan, Wednesday, July 18, 2001, 5:55:46 PM, you wrote: RC I'm wondering what people are considering best practices for JDBC calls? RC 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 RC 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.) RC ie- public boolean select(Connection cn1, String primaryKey) RC How are others doing it? I think this is a good approach, but want to see if someone has come up with something better. RC Thanks, RC Ryan Take a look to the jdbc-example in validator - it contains sample of jdbc calls similar to Command pattern. -- Best regards, Olegmailto:[EMAIL PROTECTED]
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
RE: Where do YOU put JDBC calls?
Please ignore my statement the Business Object calls the DAO's business methods. It need not always do that. You could implement a factoryObject that does it for you and by using a factoryObject you can maintain the anonymity between the Business Object and the DAO. thanks pathangi r -Original Message- From: Pathangi, Rao H. Sent: Wednesday, July 18, 2001 9:18 AM 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
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 ***
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
***
RE: Where do YOU put JDBC calls?
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
***
RE: Where do YOU put JDBC calls?
From my understanding then - I would have my Business Object class that wraps the table, lets call it Address. I would have a DAO object that is specific to that Business object for the JDBC calls, lets call it AddressDAO. In Address, I would have loadAddress, DeleteAddress, InsertAddress, all of which would call AddressDAO to do the actual JDBC call? Any simple examples of these two classes that are not EJB's? Is this the route to go if I'm not using EJB's? Thanks, Ryan [EMAIL PROTECTED] 07/18/01 08:17AM Iam using the DAO(Data Access Object) design pattern for such Data accesssituations. DAO is a layer of abstraction that works in conjunction with theBusiness Object which is nothing but a container for business data. theBusiness Object calls the DAO's business methods. The DAO's Business methodswrap the JDBC Code for data base interaction. Its been explained clearly onthe J2EE blueprints section.Once you are done writing your DAO's, extend theDAO into a session bean or use it seperately.regardspathangi r-Original Message-From: Ryan Cornia [mailto:[EMAIL PROTECTED]]Sent: Wednesday, July 18, 2001 8:56 AMTo: [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, insertthe bean values in the database, or delete the record from the database. Inall of these functions, I pass in a database connection from the action. (Orwhatever 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 ifsomeone has come up with something better.Thanks,Ryan
RE: Where do YOU put JDBC calls?
Well, I too thought about this...
Then I thought, If I leave the getConnection() open and let the DAO take
care of it, I thought the same DAO can be used for multiple datasources. The
way you get a connection does not matter.
Well, I am still 50/50 about this idea though. I am thinking of another
approach
Lets say I have an abstract class DAOFactory.(A factory that creates DAO's)
so now My ABCDaofactory extends DAOFactory. (ABCDaoFactory is a singleton)
In ABCDaoFactory, i write an init method which sets the connection
Manager(It could be an Oracle manager or a DB2Connection manager).
Also, the ABCDaofactory has a method getMyBottleOfPicklesDao() which
returns MyBottleOfPicklesDao (A data access object).
This factory would get you a ready made DAO and all you got to do is use
it.(Bruce Eckel calls these people who use these as Client Developers Hee
ha!!)
The MyBottleOfPicklesDao would extend a BAseDAO which has a concrete (not
abstract) getConnection method which says
abstract class BaseDAO
getConnection()
{
// This way you delegete the getConnection in the base class and that
connection depends on the Connection Manager //which is another layer of
abstraction that is set in the ABCDaoFactory.
conn = connectionManager.getConnection();// the connectionManager
variable is set in the factory
}
this way your DAo doesnt need to know how to get a connection
regards
pathangi r
-Original Message-
From: Geddes, Mark (ANTS) [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, July 18, 2001 9:39 AM
To: '[EMAIL PROTECTED]'
Subject: RE: Where do YOU put JDBC calls?
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
RE: Where do YOU put JDBC calls?
Ryan, you should really read the J2EE blueprints on DAO. It covers everything you need to know. Search aroun javasoft.com for the blueprints (they are documents, not software). --Steve -Original Message- From: Ryan Cornia [mailto:[EMAIL PROTECTED]] Sent: Wednesday, July 18, 2001 7:36 AM To: [EMAIL PROTECTED] Subject: RE: Where do YOU put JDBC calls? From my understanding then - I would have my Business Object class that wraps the table, lets call it Address. I would have a DAO object that is specific to that Business object for the JDBC calls, lets call it AddressDAO. In Address, I would have loadAddress, DeleteAddress, InsertAddress, all of which would call AddressDAO to do the actual JDBC call? Any simple examples of these two classes that are not EJB's? Is this the route to go if I'm not using EJB's? Thanks, Ryan [EMAIL PROTECTED] 07/18/01 08:17AM 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]] 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
RE: Where do YOU put JDBC calls?
yups ryan even iam using the same method for JDBC calls and i think that this provides quite a lot program modularity. even i want to know whether is there a much better approach for JDBC calls. Vikramjit singh, eAngel Team, Global Tele-systems Ltd. Ph. 7612929-3140 -Original Message-From: Ryan Cornia [mailto:[EMAIL PROTECTED]]Sent: Wednesday, July 18, 2001 6:56 AMTo: [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
