Re: looking for opinons regarding best practices (jdbc, resultsets,
and servlet design)
Please do not top-post. (Order corrected.)
"javerra" wrote:
Im looking for an opinion regarding best practices. Recently a friend
and I were talking about how we write our code for our web
applications. I tend to keep my jdbc code with my logic in any
servlet I am writing. My friend says that this is bad practice and
that data quries should be broken out into data access objects with
methods that pass back a result set. Is he right? Is this really bad
practice or is it really just a different type of design pattern?
Love to hear everyones thoughts...
Im always doing something like this....
try {
Connection Conn = DriverManager.getConnection("jdbc:mysql://
sql.useractive.com/USERNAME?user=USERNAME&password=PASSWORD");
// Do something with the Connection
Statement Stmt = Conn.createStatement();
ResultSet RS = Stmt.executeQuery("SELECT * from SOMETABLE");
while (RS.next()) {
out.println(RS.getString(1));
}
// Clean up
RS.close();
Stmt.close();
Conn.close();
}
catch (SQLException E) {
}
There is an advantage and a disadvantage to the DAO approach. The advantage is
that it decouples data storage logic from business-rule logic. The
disadvantage is that it somewhat increases the up-front programming effort.
Decoupling data storage allows portability to other data storage schemes
(switching from JDBC to JNDI or a Web service, for example). It allows passing
of data entity value objects around without keeping a connection open. Passing
back non-Cached RowSets or ResultSets requires an active connection.
In a data-access-object (DAO) layer approach, the DAO objects accept and pass
back entities or collections, not ResultSets. There is no consciousness by the
clients of that layer that a Connection or a ResultSet or Statement exists.
dnass wrote:
You should have a look at MVC model.
And for the code you've written I would have wrote it this way :
Connection Conn = null;
Statement Stmt = null;
ResultSet RS = null;
You dcn't actually need the extra initialization of these variables. Also, it
is conventional to name variables with a lower-case first letter, to
distinguish them from class identifiers.
try {
Conn =
DriverManager.getConnection("jdbc:mysql://
sql.useractive.com/USERNAME?user=USERNAME&password=PASSWORD");
// Do something with the Connection
Stmt = Conn.createStatement();
RS = Stmt.executeQuery("SELECT * from SOMETABLE");
while (RS.next()) {
out.println(RS.getString(1));
}
}
catch (SQLException E) {
// handle the exception
}
finally{
// Clean up
try{
RS.close();
}
catch(Exception ex){}
In real life one would likely want to log this exception. Also, some suggest
that one should not catch "kitchen_sink" exceptions.
RS = null;
try{
RS.close();
This would throw a NullPointerException.
}
catch(Exception ex){}
RS = null;
try{
Conn.close();
}
catch(Exception ex){}
Conn= null;
}
because if you have an exception while executing the query
with your source code you'll never close your connection.
javerra wrote:
I believe I have been implement an MVC design in the apps I've been
writing. My understanding is that with MVC I would have a "model" of
my data (just a plain javabean),
It doesn't actually *have* to be a JavaBean, since model classes are primarily
behavioral and not really value objects. They likely will have some
attributes, though, so in that sense they are likely to follow bean accessor
patterns.
Im using JDBC in a servlet
In the MVC pattern there would be no servlet directly accessing JDBC. That
would be done through a model class or a DAO class.
to fill my bean and do whatever processign logic needs done, this being the
"controller".
The controller is supposed to handle only parsing a request, its dispatch to
model logic, then navigation to the subsequent view. All other logic happens
in the model.
Im then, stuffing that into a request or session
attribute and sending to a jsp "view".
Stuffing what "that"? The logic object? The logic object is primarily
behavioral and should not reside as a session or request attribute. It may,
however, determine via business rules that some value object or collection
thereof should be "stuffing" for the request or session (or wherever).
I guess this still leaves me confused about whether or not I should be
handling my data access form the servlet the way I have been.
The servlet really should not be the one to talk to the data store directly,
in nearly all these architectures. That is a job left to the model.
- Lew