There's a whole world of data that we don't cover quite yet and that's the world of databases. Microsoft has "packaged" their data technology into what is now actually an "big tent" marketing name: ADO.NET.
According to Microsoft, ADO.NET includes the technology to access both Microsoft SQL Server and XML, OLE DB and ODBC. That's a big span of technologies so some of them are clearly just part of the ADO.NET "big tent" so Microsoft can say they are. One clue is that the ADO.NET objects are found in two different Framework libraries, System.Data.dll and System.Xml.dll, and neither includes "ADO" in the name. It can be confusing if you're just learning about it.
There is a whole new philosophy of data access in ADO.NET, however, and it's different from the one used previously with VB6. If there is such a thing as ADO.NET (other than marketing and advertising), this new philosophy of universal data access is it. Universal data access was also a key goal of the previous ADO (no ".NET").
New students of programming sometimes find it confusing to learn that the way data access is being made easier and faster is to introduce more steps in the process. How can more steps make it easier? One way is that the same kinds of objects now work for everything. The do this by separating data access from data manipulation.
There are two main objects in ADO.NET:
- DataReader: When the best way to process data is one record at a time. Although it isn't flexible - DataReader only lets the program read data in sequential order - it's faster than any other way you can do it. In fact, DataAdapter (below) uses DataReader to fill a DataSet. DataReader is the closest thing in ADO.NET to the way we used to process data.
- DataAdapter: Used with a DataSet object for flexible and often web oriented data access is needed. If you need to use SQL, you'll use the DataAdapter. If your data is XML, you'll use the DataAdapter. In fact, the native format of ADO.NET data is XML, so you can create an XML version of the data regardless of where it was originally.
The DataSet
Using the ADO.NET DataSet Class, it's important to understand that ADO.NET connects to a datastore, retrieves the data, and disconnects again. In the "old world" of files, a datastore would be opened and kept open as long as the program was running. (Microsoft calls this the "connection-based, two-tier model.") This doesn't work at all in the "n-tier" world where a complete system consists of "n" separate programs executing independently. The same datastore might be accessed in parallel by hundreds, maybe even thousands, of on-line users. Any one application has to get in and get out almost instantly.
To do this, ADO.NET uses a new class, called the DataSet class, that is designed specifically to hold data temporarily while it's being processed. The idea is to ...
- Connect to a database and create a temporary datastore using objects in the DataSet class.
- Read or update that temporary datastore.
- Connect again, if necessary, to update the permanent database.
Data access is completely removed from data manipulation this way.
The DataSet class is no flat view of the data. A DataSet can include a collection of DataTable objects that can be related with DataRelation objects and can also include integrity rules like UniqueConstraint and ForeignKeyConstraint. So you can think of it as being an in-memory database.
The recommended way to send data across a network in ADO.NET is XML. ADO.NET includes objects that can read and write data as XML documents for transmission across networks as ordinary text.
LINQ - The Newest ADO.NET Technology
LINQ - Language INtegrated Query - was introduced in Framework 3.5 in November, 2007, so you have to use VB.NET 2008 to use LINQ.
Before LINQ, you had to code a statement to access your data to match the source of the data. In other words, if your data was in a SQL database, you had to code SQL. LINQ is "SQL-Like" but it isn't SQL. This SQL statement ...
Dim strSQL as String = _
"SELECT Name, CustomerID FROM Customers"
... becomes this LINQ coding ...
Dim customers = From cust In Customers _
Select cust.Name, cust.CustomerID
LINQ lets you code queries directly in Visual Basic. The data is then returned as strongly-typed objects (an integer really is an integer) and you get the benefits of IntelliSense for faster coding. The data objects returned by LINQ can be the source of more queries in your program and you can bind these LINQ objects to controls.
In this segment, we're going to use LINQ with XML, but Microsoft designed LINQ to work with a variety of data sources such as SQL databases too. The idea is to add a whole new way to get data into your program that will work now and in the future.
LINQ lets you embed XML directly in your code as in this example:
Imports <xmlns:ns="http://www.visualbasic.about.com/">
Module XMLSample
Sub myXML()
Dim customer = _
<ns:customer>
<ns:firstName>George</ns:firstName>
<ns:lastName>Washington</ns:lastName>
</ns:customer>
End Sub
End Module
Since ADO.NET is such a broad sweep of new technologies, it's necessary to focus in on just part of it as an introduction. On the next page, we introduce the concept of serialization - one of those key technologies that is used much more in ADO.NET.
