Hi All,
I have found a very good article which does solve most of the problems
using design patterns.
The article "Applying Patterns to JDBC: Buiding a lightweight
Object-Relational Mapping
Framework" by Frank Sauer appeared in JavaReport magazine in May, 2001.
Thanks all,
-ShriKant
"A mailing list for discussion about Sun Microsystem's Java Servlet API
Technology." wrote:
> Does somebody has some more clue about this issue.......................
> Please enlighten.
>
> -ShriKant
>
> "A mailing list for discussion about Sun Microsystem's Java Servlet API
> Technology." wrote:
>
> > First of all I want to clarify that I am not using entity beans to
access
> > database. I
> > appreciate your understanding about the usage of J2EE pattern. This
> pattern
> > is all about
> > resource independency, that means, after using that pattern, I need not
> > worry whether my
> > query is being processed by Oracle, Sybase, XML datastore etc. But I
> think
> > that is a separate
> > issue (resource independency).
> >
> > Here what I am worried of is, it may mean as many classes (read
> > implementation classes) as
> > there are tables and queries. It may become difficult to manage when we
> > have a large database
> > and schema. May be I am going to same line where you are. I want to put
> > that kind of
> > implementation in native SQL instead of Java classes. That means, there
> > should be some kind
> > of common interface which could interact with the query parameter,
query
> > identifier; and just
> > pass them to corresponding implemention of SQL. The interface should be
> > single controller to
> > manage it. I don't know how far is it possible. Any takers............
> >
> > -ShriKant
> >
> > "A mailing list for discussion about Sun Microsystem's Java Servlet API
> > Technology." wrote:
> >
> > > Well. It all depends on how you access the DB whether thru Entity
> beans,
> > > direct Sql drivers etc., As you might know there is a j2ee pattern
> called
> > > "Data Access Objects(DAOs)" using which you can do these. It's
nothing
> > but
> > > kind of using the power of interfaces in Java. For example, you can
> > declare
> > > an interface with business methods. Let's say you need to access a
user
> > > table. Then you may have,
> > >
> > > public interface DBAccess{
> > > public void addUser(UserInfo ui) throws SQLException;
> > > public void deleteUser(String userId)throws SQLException;
> > > public void modifyUser(UserInfo modifiedUser)throws SQLException;
> > > public UserInfo getUser(String userId) throws SQLException;
> > > public void getUsers()throws SQLException;
> > > }
> > >
> > > You can write implementaion classes for this interface depends on the
> > > Database you use. The code to add/modify/delete data into/from a
> database
> > > will reside in a single place(implementation classes) which will lead
> you
> > > to a better maintainalbe code.
> > >
> > > For example, you may use a RDBMS, ordinary DBMS even flat files. As
> long
> > as
> > > your code talks to an interface, you can plug in the implementations.
> > >
> > > For example you use two kinds of DBs in your code. Then,
> > > DBAccess db = DBAccessFactory.getInstance("Oracle");
> > > UserInfo ui = db.getUser("shri");
> > > db.deleteUser("shri");
> > > db = DBAccessFactory.getInstance("SQLServer");
> > > db.addUser(ui);
> > >
> > > So even if you change the implementation classes, your code still
> works.
> > > I don't prefer going for stored procedures and writing methods which
> > takes
> > > a Query as an argument. If you want this only, then that is what your
> > > statement/prepared statements do.
> > >
> > > -----Original Message-----
> > > From: ShriKant Vashishtha [mailto:[EMAIL PROTECTED]]
> > > Sent: Monday, January 28, 2002 5:37 PM
> > > To: [EMAIL PROTECTED]
> > > Subject: Re: Connection in JSPs?
> > >
> > > Is there a generic approach/pattern/framework by which we just need
to
> > > specify the query
> > > parameter and that will give us the respective response. I want to
use
> a
> > > common interface
> > > (and put it into a Class) for all the sql ueries for all the JSP
which
> > > should not be
> > > dependent upon the query parameter and type of query. One possible
> > solution
> > > I can think of to
> > > use the stored procedure for all JDBC related work and pass them the
> > > necessary parameters
> > > required and get the response in return. But at present I am not very
> > sure
> > > of the pros and
> > > cons of this strategy. Is there any other possible solution. Please
> > > enlighten...........
> > >
> > > -ShriKant
> > >
> > > "A mailing list for discussion about Sun Microsystem's Java Servlet
API
> > > Technology." wrote:
> > >
> > > > You can write an utility class kind of thing like
ConnectionPool.java
> > > which
> > > > has methods like public Connection getFreeConnection() and public
> void
> > > > returnConnection(Connection c).
> > > > Make sure that you don't close the connections in your JSPs after
> use.
> > > Let
> > > > the same utility class close the connections when it decides they
are
> > not
> > > > necessary.
> > > > So that you can have the code two aquire a DB connection in one
> place
> > > > which will be easier when you might change the server/driver etc in
> > > future.
> > > > -----Original Message-----
> > > > From: Sumit Mishra [mailto:[EMAIL PROTECTED]]
> > > > Sent: Monday, January 28, 2002 10:31 AM
> > > > To: [EMAIL PROTECTED]
> > > > Subject: Connection in JSPs?
> > > >
> > > > Hi,
> > > >
> > > > What can be the best way of taking connection in a JSP when u have
to
> > > fire
> > > > a query in almost every JSP? Is the useBean approach ok??
> > > >
> > > > Regards,
> > > > Sumit
> > >
> > >
> >
>
___________________________________________________________________________
> > > To unsubscribe, send email to [EMAIL PROTECTED] and include in
the
> > body
> > > of the message "signoff SERVLET-INTEREST".
> > >
> > > Archives: http://archives.java.sun.com/archives/servlet-interest.html
> > > Resources:
http://java.sun.com/products/servlet/external-resources.html
> > > LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
> >
> >
>
___________________________________________________________________________
> > To unsubscribe, send email to [EMAIL PROTECTED] and include in the
> body
> > of the message "signoff SERVLET-INTEREST".
> >
> > Archives: http://archives.java.sun.com/archives/servlet-interest.html
> > Resources: http://java.sun.com/products/servlet/external-resources.html
> > LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
>
>
___________________________________________________________________________
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the
body
> of the message "signoff SERVLET-INTEREST".
>
> Archives: http://archives.java.sun.com/archives/servlet-interest.html
> Resources: http://java.sun.com/products/servlet/external-resources.html
> LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
