| You may wonder why Microsoft felt it necessary to start over again, putting ADO "out to pasture" and moving on to ADO.NET. Wasn't ADO good enough? It isn't that ADO was not good enough; rather, developer's needs have changed. The biggest difference between ADO.NET and ADO is that ADO.NET was constructed, from the ground up, to support disconnected manipulation of data. With ADO.NET, you read through the data using a forward-only, read-only stream. If you need to work with a set of data, you retrieve a cached version of the data you need, work with it in a disconnected environment, and then send updates back when you're done. Certainly, ADO's connected model requires less thought on the part of the developer. You connect to data, do your work, and disconnect when you're done. It may take a while to "get the hang" of the new object model and how it all fits together. However, we've been convinced, and we hope that over the course of the next few chapters you buy into it as well. The following list describes some of the areas where ADO.NET excels over ADO: Performance. ADO.NET uses a disconnected architecture, allowing static data to be stored in memory and requiring fewer roundtrips to the database. (Of course, ADO supported disconnected recordsets as well, but the support was limited, and this wasn't the way most developers used ADO.) In addition, COM developers always had to pay the price of marshalling ADO recordsets from tier to tier in a multitiered application. In ADO.NET, data is normally transported as XML, thus reducing the need for translations. Scalability. A disconnected scenario is often superior, in terms of scalability, because you never have users maintaining lengthy connections to the database and using up valuable resources. Instead of tying up database connections and locks, ADO.NET clients retrieve the data, disconnect, and release their resources. Interoperability. ADO.NET transports data as XML. This means that it is easy to pass data from one component to another, because XML is pure text. Components can be on the same machine, different machines, or separated by the Internet, and they can even be on different operating systems. This makes interoperating between these various components easy and flexible. XML is supported by every modern operating system and platform, and even non-.NET clients can consume the data provided by ADO.NET. Programmability. Visual Studio .NET provides tools to create classes that "wrap up" DataSets, providing methods and properties for working with a specific schema. These classes, named typed DataSets, make it easier to interact programmatically with the DataSet. If you choose to use typed DataSets, you get extra design-time benefits. Typed DataSets provide strong data typing when working with columns within your DataSets. In addition, they also provide properties that represent the columns within your data. For example, if you had created a DataSet containing a DataTable named Customers and you wanted to retrieve the AvailableCredit column from row 3, you might write code like this: credit = _ ds.Tables("Customers").Rows(3)("AvailableCredit") Using a typed DataSet, you could rewrite the same code as this: credit = ds.Customers(3).AvailableCredit The code for the typed DataSet is both easier to read and easier to write, because Visual Studio can provide IntelliSense as you enter column names. The code for the typed DataSet is safer, as well, because it provides for compile-time checking of types. For example, suppose that AvailableCredit is a Decimal type. If the programmer erroneously assigns the AvailableCredit column to a String variable, Visual Studio .NET would report the error to the programmer at compile time. When working with a standard DataSet, the programmer wouldn't learn of the error until runtime. TIP When you work with a typed DataSet, you're creating an instance of a particular class that inherits from the DataSet object. This class provides properties that have the same name as the columns within the underlying DataSet, and these properties supply the data you're working with. When you refer to a column, such as ds.Customers, you're actually referring to a property of the typed DataSet class, not a real column within the DataSet. It's a subtle distinction, but it's important to understand that you're interacting with a class that Visual Studio .NET generated for you, not with the actual DataSet itself. All the source code is available there's no hidden magic. You can investigate and study the typed DataSet source code that's available as part of your project once you create the class.
|
