Simplify JDBC database access
The generation of the problem:
In some small applications, JDBC plays a role that makes people feel difficult. I have encountered such a problem recently: the project is not big, can't make a persistent technology such as Hibernate, but the large number of repetitive code brought by JDBC has a more difficult job.
The traditional database Query method is like this:
Construct SQL Statements -> Get the connection pool -> Create STATEMENT -> Execute SQL Query Request -> Processing ResultSet -> Close Results and Statement -> Release Connection
The rough code is as follows:
String SQL = "SELECT NAME, Pass from table where id = '" ID "" "
CONNECTION CONN = ConnectionPool.getConnection (); statement stmt = conn.createstatement (); resultset = stmt.exequery (SQL);
While (rs.next ()) {// .......}
Rs.close (); stmt.close (); connectionpool.release (conn);
This brings a question: Since there is such a set of rows at a time inquiry, once you change the strategy of getting and releaseing the Connection, the workload of maintenance is huge. If you want to reduce the number of Ctrl-C and Ctrl-V like me, please continue to look down.
analysis:
In fact, there are only two places we have concerned. Constructs SQL statement 2. Handling the resultSet process is a simple repetition, according to the principle of reconstruction, because the repetitive code is minimized, and more attention is concentrated on the process of ResultSet.
Suppose we have a function called DOQUERY to unify the Query process. Maybe you will think of the construction of SQL to DoQuery, then return a resultset, then processes the resultSet, this doquery looks like this: public resultSet doQuery (String SQL) {Connection conn = connectionPool.getConnection (); statement Stmt = conn.createstatement (); resultset = stmt.exequery (); // Resultset also closes ConnectionPool.Release (conn); Return RS;} looks good, but do this You can't handle ResultSet, because the Resultset is also closed while Statement is closed. So you must create, processed and shut down the ResultSet in the same function.
solution:
The solution is to pass the process of constructive SQL and process the resultset to DOQUERY. However, how do you achieve it? Don't forget that Java is OO. What is the first major characteristic of OO? Pair, package. We can pack the results of the ResultSet. The specific method is as follows:
First we need to define a query interface for each query request. Inside the interface: interface query {public string getsql (); // Get this query SQL PUBLIC OBJECT DOPROCESS (RSET RS); // encapsulates the processing of ResultSet} The following round to our legendary DOQUERY function The appearance: Class Dbtool {public static object doquery (query query) {connection conn = connectionPool.getConnection (); statement stmt = conn.createstatement ();
String SQL = query.getsql (); // Get this query SQL ResultSet RS = Stmt.exeQuery (SQL); // Create a ResultSet Instance Object O = Query.Doprocess (RS); // Complete to ResultSet Process
rs.close (); // This closing results will not have any problems :) stmt.close (); connectionpool.release (conn);
Return O;
} To express it, the above is a simple frame, omitted TRY - Catch and some of the partial fault tolerance judgment.
Everything is available, how to use it? Do you have to write a class that implements Query every time a query? Of course! Otherwise, don't you do more. Remember the method of processing Listener in swing. We can use an anonymous internal classes to implement:
Object o = dbtool. Doquery (new query () {// anonymous internal class public string getsql () {String SQL = "Select Name, Pass " "" id "" Return SQL;}
Public Object Doprocess (ResultSet RS) {Vector Vector = New Vector (); user user = null; while (rs.next ()) {user = new user (); user.setname (rs.getstring ("name")) User.SetPass (rs.getstring ("pass")); Vector.Add (user);} Return Vector;}} // end new query ()
);
// Although it is possible to throw ClassCastException but the type of return value here should be a clear vector vector = (Vector) O;
Only there is only our concern for the construction of SQL and the part of the resultset, is it more refreshing :)
Summary: DoQuery uses a template mode mode of "Don't Call US, We Well Call you", which can be independent of the code part we care.
Similarly, we can also implement two methods in doupdate () and doexecute () in douptool, because it is not involved in ResultSet, so it is necessary to achieve much. Not much here.
This way we use a DBTOOL to help us simplify all database operations, save a lot of repetitive code, fast and fast :)
Blue Mountain Coffee. 2004.8.21 Night
