VB.NET数据库外文文献及翻译
Database Access withVB.NET and ADO.NET
The vast majority of applications today have to perform some sort of database access. Whether you are building Windows applications and want to perform simple database access, or you are creating middle-tier components to handle database access, understanding how to connect to a database, retrieve information, and manipulate data are critical to understanding how to move to VB.NET.
First, VB.NET introduces new tools for connecting to databases. Some of these tools are controls that act as wrappers around the database access objects, called ADO.NET. These controls simplify the code you write, and allow you to bind graphical controls to DataSets you generate from the database. These controls require a new way of working with data-bound controls in your application.
Second, ADO has evolved into ADO.NET. The ADO.NET functionality is different from what you are used to with ADO. Although similar in concept, the ADO.NET objects follow a disconnected paradigm. One of the major differences is that you are not necessarily retrieving the equivalent of a recordset, but an entire schema structure.
About ADO.NET
As I’ve mentioned many times before, ADO.NET uses a disconnected architecture to operate. The reason for this is that traditional applications that maintained an open database connection did not scale well. If a component opened a connection to the database and held it open for the lifetime of the application, it consumed expensive database resources, when the connection probably was needed for only a small percentage of that time. As the number of users grows, the overhead of the database connections can begin to affect the database performance negatively. Therefore, Microsoft decided to use a disconnected architecture for ADO.NET. This not only solves the problems with scalability by reducing the number of active connections, it makes it much easier to transfer data from one component to another. You do not need to have both components connected to the database, nor do you have to have them both understand some binary format of the data, as you will see in a moment.
Additionally, Microsoft recognized that in much programming today, you basically have a disconnected application architecture, thanks to the Web. Think of a typical Web application: The user requests a page and the page is generated on the server, with a mix of HTML and data from the database. By the time the page is sent back to the user and rendered in his browser, the connection to the database is no longer needed. Therefore, if it takes one second to render a page but the user views it for twenty-nine seconds, a database connection is needed for only one-thirtieth of the total time the page is used. If you still need to use a connected architecture, Microsoft recommends you use ADO. ADO.NET is inherently disconnected, so ADO is still a better approach if you need a continuous connection to the underlying database.
DataSets
ADO.NET uses the DataSet to store disconnected data. This new structure is similar to an ADO recordset, but it has some important differences. For example, an ADO recordset looks like a single table, even if the data is from multiple tables. The final recordset is merely rows and columns. A DataSet, however, can store multiple tables in its cache. You can define the relationships between these tables, and then read from individual tables or join tables and retrieve data. A DataSet, in a sense, works like a miniature copy of the database, although it usually contains only a small subset of the data or the tables. A DataSet knows nothing about the underlying database. In fact, multiple underlying databases could make up the data in a DataSet. There is no reason why some of the data couldn’t be from SQL Server while other data comes from Oracle. Another 原文请找腾讯752018766优,文^论~文.网http://www.youerw.com SQL statements or stored procedure names. Datasets know all about XML. If you need to pass a DataSet’s data from one component to another, the data is passed using XML. If you want to write a DataSet to disk to be able to retrieve it later, it is stored in XML format. ADO.NET uses XML because it is a standard format, and any consumer that understands XML can use that XML stream, transforming it as desired into whatever format is necessary. Contrast this to an ADO recordset, and you can see the advantages. An ADO recordset uses a binary format that has no meaning on another platform. XML, however, is a textbased standard that can be consumed by any platform. Further, that fact that XML is text means that it is quite easy to transfer it over HTTP.
NOTE：
Actually, ADO has allowed you to persist a recordset as XML for a while. However, this is not the default format; instead, you must call the Save method and pass a parameter to specify the XML format. XML is the default in ADO.NET. Another advantage to using XML as the transport is that unlike ADO’s disconnected record sets, passing a DataSet to another component is as simple as transferring text. With a disconnected recordset, you had a binary file that had to be marshaled across process boundaries, which was an expensive proposition.
Working with the ADO.NET Objects
There are a number of new objects in ADO.NET that are different from what ADO developers have been using. Some of the names sound similar to the names of ADO objects, but be careful that you don’t assume certain capabilities that might not exist. You’ve already seen a discussion of the DataSet, but this is like starting an ADO discussion with the recordset: It’s where you do most of the work, but it’s the endgame as far as the coding goes. Therefore, with ADO.NET, you need to understand how to make the database connection, and how to execute the statements that end up filling in the DataSet.
Connections: oleDbConnection and SQLConnection
The oleDbConnection object uses OLE DB to connect to a data source. ADO.NET also includes a new type of connection: SQLConnection. This works like the oleDbConnection object, but it does not use OLE DB. Instead, SQLConnection uses a native driver to connect to SQL Server and offers better performance than the OLEDB provider. Because some people reading this book might not have access to SQLServer, I will continue to use oleDbConnection.。Connecting to a data source is straightforward: Define the connection string, create the connection object, and open the connection.
OleDbCommand and SqlCommand
When you call the Open method, you open a connection to the database. Now, you need to create a command to run against the database. You do this by creating an OleDbCommand object (or SqlCommand object if you are using a SqlConnection).
You have now established a connection to the database, and you have created a command to retrieve the records. As in ADO, however, you can’t store those records in a connection or a command. Instead, you must have an object that can hold those records.1654