Talk about ADO .NET VS JDBC

zhaozj2021-02-16  76

I have had a development experience of about three years under .NET, I can say that I am very familiar with ado .net. The maximum feature of ADO .NET is a full-scale support for disconnecting. It introduces DataSet, DataTable, DataRow, etc. , Give the user an intuitive way of use. ADO .NET also can make data bonding with controls of ASP .NET and Windows Form, making it easy to write some small procedures. When I started to turn to the Java platform, I found that JDBC didn't have these characteristics. I didn't have used it. I feel that JDBC is very difficult. Some colleagues who are accustomed to Ado .Net, I also plan to develop a set of Dataset, DataTable. Under the Java platform, it has been more than a year. In this year, the views of JDBC slowly have changed, and also thinking about ADO .NET, many of the advantages of JDBC, also found ADO. Some defects in NET. Today I have a rough reading of JDBC 3.0's norms, and organize some ideas as follows: 1. ADO .NET's biggest advantage is to disconnect the connection to access database mode powerful support. Compared to the JDBC also introduces similar functions, RowSet, but is not enough than ADO .NET. 2, ADO .NET function is incomplete. MS is also recognized by this, admitting ADO .NET can't replace ADO. One of the important features is to paid support for access data. Previously, when developing the ADO .NET program, a program is also written, calling ADO, page acquisition data. 3, some interfaces of ADO .NET are inappropriate: A. It is not good for interface programming. Especially in .NET Framework 1.0, the problem is particularly serious. For example, you want to program the following code based on interface programming:

IDBConnection CONN

=

;

//

It is impossible to obtain the corresponding Connection implementation only through the URL, and you need to write a tool class yourself.

IDBCommand Command

=

Conn.createCommand (); IDATAADAPTER DATAADAPTER

=

;

//

How can this be built?

In .NET Framework 2.0, the situation is improved, you can write this:

DBPROVIDERFACTORY Provider

=

DBProviderFactories.getFactory (

"

"

IdbConnection Connection

=

Provider.createConnection (); IDATAADAPTER Adapter

=

provider.createdDataAdapter ();

In .NET Framework 1.x, ADO .NET is definitely not seriously considered based on interface programming, while JDBC is initially designed, it is based entirely on interface programming. In .NET Framework 2.0, Microsoft aware of its short-sighted behavior, adds DBProiderFactory interface, but I think it is worse than JDBC. In JDBC, you can write this:

String URL

=

"

JDBC: mysql: //127.0.0.1/mysql

"

String Username

=

"

SA

"

String Password

= ""

Connection conn

=

Drivermanager.getConnection (URL, Username, Password);

In JDBC, with ADO's Connectionstring is a URL, JDBC Driver's URL format is: JDBC: : Different Driver implementations, knowing different subprotocol. You can load a DRIVER dynamically, for example:

Drivermanager.RegisterDriver

New

MyDriver ());

Different Driver identify its own Subprotocol by implementing AcceptsURL. For example, a DRIVER implementation:

public

Boolean Acceptsurl (String URL) THROWS SQLEXCEPTION

{IF (URL! = Null && Url.StartSwith ("JDBC: KSQL:")) {Return true;} Return False;

3, JDBC's data source acquisition mode variety: a, directly access B through the DRIVERMANAGER.GETCONNECTION, get a connection through the data source of the application server. E.g:

//

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 iptain a database connection connection

DataSource DS

=

(DataSource) CTX.lookup

"

JDBC / ACMEDB

"

Connection Con

=

DS.GetConnection

"

User

"

,

"

PWD

"

);

In .NET, there is no similar 咚咚咚. 4, ADO .NET does not include interfaces of distributed transactions, ADO .NET distributed transactions are managed by MS DTC. JDBC itself provides interfaces that support distributed transaction support, and different JDBC Driver implements this interface to support distributed transactions. 5, ADO .NET, different ADO .NET Provider's parameter format is different. Both OLEDB and ODBC use anonymous parameters, SQLClient uses "@" named parameters, OracleClient uses ":" starting naming parameters. This is obvious that people cannot be based on interface programming. When using ADO .NET, in order to interface programming, you must write a lot of tools yourself, which is annoying! 6. Some of the hierarchical structures of JDBC are unreasonable. One of the obvious is Statement, PreparedStatement, Callablestatement inheritance relationship is unreasonable. ADO .NET does not have this question 7. In JDBC, the parameter count starts from 1, and the initial user is easy to make mistakes. ADO .NET does not have this question JDBC is a specification, a standard, while ADO .NET is just Microsoft's private class library. .NET Framework is currently a standard class library, there is only one small part, and .NET moves to open roads! Mono's ADO .NET implementation, I don't know if Microsoft constitutes an infringement behavior? Summary A, JDBC is open, the frame design is good, but there are some small defects in some details. B, ADO .NET is easy to use, support for disconnective data access is good, but the overall design and openness are slightly poor. 2004-07-28 04:07 Author: less temperature

转载请注明原文地址:https://www.9cbs.com/read-12269.html

New Post(0)