Solution Architecture

Microsoft’s first attempt at solving the problem of universal data access from a single programming model was OLE DB, released around 1995. That’s so long ago in geek years that COM was still called OLE (a MINFU; see Chapter 4), and the author of the Microsoft Systems Journal article about the technology provided a CompuServe number (70313,1455) as a contact address. In OLE DB, every data provider implemented a standard set of interfaces for allowing external access that required no knowledge by clients of the data provider’s internal implementation. This process is illustrated in Figure 6-1.

OLE DB provided a single programmatic interface for all providers of data.

Figure 6-1: OLE DB abstracts away the differences between different data providers.

It was a good idea and a good first try, but OLE DB^[1] was hard for clients to program against, particularly in Microsoft Visual Basic. Microsoft next released ActiveX Data Objects (this was during the brief period when all things COM were called ActiveX, another MINFU), which Visual Basic programmers seized with cries of delight because it was so much easier (well, relatively) for them to program. ADO’s front end provided an easier interface for clients to program against, and its back end spoke OLE DB to the provider, as shown in Figure 6-2. ADO worked fairly well on a Microsoft-only intranet and on the middle tier of a three-tier system accessed by Web clients. But ADO doesn’t scale well to the open Internet. It uses DCOM to cross machine boundaries, which means that it can’t easily work with non- Microsoft systems and has trouble getting through firewalls at Microsoft-only systems. ADO supported a limited amount of disconnected operation, but it was designed for and worked best in the connected case. It was a good solution for the problem it aimed at, but programmers’ needs have changed in the modern Internet world.

ADO made OLE DB easy for programmers to use but worked well only in a Microsoft-only environment.

Figure 6-2: ADO object using OLE DB.

Microsoft .NET introduces ADO.NET, Microsoft’s architecture for transferring the ideas of universal data access and easy programming from the COM-based world of ADO into the .NET world. ADO.NET is conceptually similar to ADO in the sense that it is a data abstraction layer that smooths over differences between data providers and includes prefabricated objects and functions for easy access to data.

.NET provides data access via ADO.NET.

A data provider that wants to make its data available to .NET clients via ADO.NET implements a standard set of .NET objects that connect the data provider to interested clients. These objects are Connection, DataAdapter, Command, and DataReader. A full description of these objects and their functionality requires examples, so I discuss them in the next section of this chapter. The developer of a data source can write his own implementation of these objects that is optimized for that particular data source, in the same manner as each data source today provides its own implementation of the OLE DB objects. Microsoft has provided an implementation of these objects for SQL Server, and these classes are part of the .NET common language runtime. In addition, the common language runtime provides an implementation of these objects that works with any OLE DB provider, so any current data provider that speaks OLE DB speaks ADO.NET automatically as well, as shown in Figure 6-3. Version 1.1 of the .NET Framework added an implementation of these objects customized for Oracle databases. Other data providers can choose whether to write their own managed implementation of these objects or whether to write an OLE DB interface and use the compatibility layer.

The .NET common language runtime provides objects that access SQL Server and also any OLE DB provider.

Figure 6-3: ADO.NET architecture and objects.

ADO.NET provides its actual data in the form of a DataSet object, as shown in Figure 6-4. DataSet is a .NET class that represents a collection of data that results from one or more queries. It contains internal tables and provides methods that allow access to the tables’ rows and columns. It also contains a schema describing its internal structure. A DataSet object can be untyped (the default), in which case a client asks for items by specifying their names in the form of coded strings. Alternatively, you can create a typed DataSet object that contains member variables tied to each individual field, which is easier to write good code for. Either type of DataSet object is compatible with .NET’s XML serialization capability described in Chapter 7. This means that it knows how to convert itself into and out of XML so that it can be transmitted across process or machine boundaries.

The server provides an ADO.NET DataSet object containing the result of a query.

Figure 6-4: The ADO.NET DataSet object.

One of the main operations that programmers might want to do with a DataSet object when they get one is to display its contents to the user. Both Windows Forms (see Chapter 5) and Web Forms (see Chapter 3) contain controls that know how to take a DataSet object and render its contents for display to humans.

Windows Forms and Web Forms contain controls for displaying DataSet objects.

This chapter provides the briefest glimpse into the features in ADO.NET. Like Windows Forms, in fact, and like every chapter of this book, ADO.NET needs a book of its own. Microsoft Press has published Microsoft ADO.NET (Core Reference), by David Sceppa, in May 2002 and Building Web Solutions with ASP.NET and ADO.NET, by Dino Esposito (February 2002).

If they need it for backward compatibility, .NET programs can still use original ADO via the COM compatibility feature discussed in Chapter 2.

^[1]You can see that as long ago as seven years, Microsoft foresaw the exhaustion of even the 456,976 unique FLAPs (Four-Letter Acronym Packages, FLAP itself is a FLAP, see Chapter 4) and started experimenting with alternatives. They’ve dusted off the FLEAP (Five Letter Extended Acronym Package, FLEAP itself is a FLEAP), which has a long and honorable history of military uses. Dwight David Eisenhower, for example, commanded SHAEF, the Supreme Headquarters Allied Expedition ary Force in the Second World War. While the use of FLEAPs hasn’t crossed into the civilian sector, probably because there hasn’t been any real need for them, 11,881,376 unique FLEAPs exist, so that ought to hold us for a while. If users balk at another increase in word length, the alternative would be to combine FLAPs, for example, CLOS, the Common LISP Object System. I call these FIAFs, which stands for FLAP Inside Another FLAP. And naturally, FIAF itself is a FIAF. When we exhaust the supply of FLEAPs, we can go to what I call the SLEAPE (pronounced “sleepy”), which stands for “Six Letter Extended Acronym Package, Eh?” (I coined this one just after a gig in Canada.) There are roughly 309 million SLEAPEs in a 26 letter alphabet, and the only one I’ve ever seen used is PCM CIA (People Can’t Memorize Computer Industry Acronyms).