Let's talk about ADO. NET vs JDBC.

I have been developing in. NET for about three years. I am very familiar with ADO. NET. ADO. NET's biggest feature is its comprehensive support for disconnected methods. It introduces DataSet, DataTable, DataRow and other objects, and builds a simplified version of "Memory Database, dataAdapter fills the data of DataReader into the able or DataSet, giving users an intuitive way to use it. ADO. NET can also be used with ASP. NET and Windows Form Controls for data bonding, making it easy to write some small programs.

When I first switched to the Java platform for development, I found that JDBC didn't have these features and I was not used to them all at once. I felt that JDBC was very difficult to use and I was used to ADO. NET colleagues, but also intend to develop a set of similar DataSet, DataTable.

I have been developing applications on the Java platform for more than a year. Over the past year, my views on JDBC have gradually changed. At the same time, I think about ADO in turn. NET, found many advantages of JDBC, also found ADO.. NET. After reading the JDBC 3.0 specification, I sorted out some ideas as follows:

1The biggest advantage of ADO. NET is its strong support for the method of disconnecting and accessing the database. In comparison, JDBC also introduces similar features, RowSet, but it is not enough compared with ADO. NET.
2And ADO. NET functions are incomplete. MS also acknowledges this and acknowledges that ADO. NET cannot replace ADO. One of the most important functions is the support for paging data access. In the past, when developing the ADO. NET program, we also wrote a program to call ADO and retrieve data by page.
3Some interfaces of ADO. NET are not properly designed:
A. Poor Support for interface programming. Especially in. NET Framework 1.0, the problem is particularly serious. For example, you want to compile the following code based on interface programming:

IDbConnection conn =; // you cannot obtain the corresponding Connection implementation only through the URL. You need to compile the tool class on your own.
IDbCommand command = conn. CreateCommand ();
IDataAdapter dataAdapter =; // how to build this?

In. NET Framework 2.0, the situation has been improved and can be written as follows:

DbProviderFactory provider = DbProviderFactories. GetFactory ("");
IDbConnection connection = provider. CreateConnection ();
IDataAdapter adapter = provider. CreateDataAdapter ();

In. NET Framework 1. x, ADO. NET certainly did not seriously consider interface-based programming. In the initial design of JDBC, it was completely based on interface programming .. In NET Framework 2.0, Microsoft realized its short-sighted behavior and added the DbProiderFactory interface, but I think it is better than JDBC.
In JDBC, you can write as follows:

String url = "jdbc: mysql: // 127.0.0.1/mysql ";
String userName = "sa ";
String password = "";
Connection conn = DriverManager. getConnection (url, userName, password );

In JDBC, The ConnectionString with ADO is a URL. The URL format of the JDBC Driver is:
Jdbc: <subprotocol >:< subname>

Different Driver implementations and different subprotocol. You can load a Driver Dynamically, for example:

DriverManager. registerDriver (new MyDriver ());

Different drivers use acceptsURL to identify their subprotocols. For example, the implementation of a Driver:

Public boolean acceptsURL (String url) throws SQLException {
If (url! = Null & url. startsWith ("jdbc: ksql :")){
Return true;
}

Return false;
}

3JDBC data sources can be obtained in a variety of ways:
A. directly obtain the connection through DriverManager. getConnection
B. Obtain the connection from the data source of the application server. For example:

// Get the initial JNDI naming context
Context ctx = new InitialContext ();
// Get the DataSource object associated with the logical name
// "Jdbc/AcmeDB" and use it to obtain a database connection
DataSource ds = (DataSource) ctx. lookup ("jdbc/AcmeDB ");
Connection con = ds. getConnection ("user", "pwd ");

In. NET, there is no such thing.
 
 4And ADO. NET do not include distributed transaction interfaces. The distributed transactions of ADO. NET are managed in a unified manner through ms dtc. JDBC itself provides interfaces that support distributed transactions. Different JDBC drivers implement this interface to support distributed transactions.
 
 5In ADO. NET, the parameter formats of different ADO. NET providers are different. Both OleDb and Odbc use anonymous parameters. SqlClient uses Named parameters starting with "@" and OracleCLient uses Named parameters starting. This obviously makes it impossible to program based on interfaces. In the past, when using ADO. NET, to program based on interfaces, you must compile a lot of tool classes by yourself, which is annoying!
 6, JDBC class level structure is unreasonable. One obvious reason is that the inheritance relationships of Statement, PreparedStatement, and CallableStatement are unreasonable. ADO. NET does not have this problem
 7In JDBC, the parameter count starts from 1, and users are prone to mistakes at first. ADO. NET does not have this problem
JDBC is a standard, while ADO. NET is only a private class library of Microsoft .. NET Framework is currently a small part of the standard class library, and there is a long way to open. NET! MONO's ADO. NET implementation does not know if Microsoft constitutes an infringement?
Summary
A. JDBC is open and the framework is well designed, but it has some flaws in some details.
B. ADO. NET is easy to use and supports disconnected data access, but its overall design and openness are slightly lower.