924 Chapter 20 DATABASES: ARCHITECTURE AND BASIC CONCEPTS

We’ll use this stored procedure in the following chapter in a short application that demonstrates how to execute a stored procedure from within your VB code and how to get the results back.

Summary

It’s been a long chapter but certainly interesting. You’ve learned how data are stored in databases, how to break the information into smaller pieces and store it into tables, and how relationships between tables allow you to quickly locate the information you’re interested in.

All actions against databases are performed with SQL statements and stored procedure. SQL is a universal language for accessing data in databases. SQL is not a traditional language, in that it describes the actions you want to perform to the database but not how these actions will be carried out. ADO.NET is based on SQL (SQL statements and stored procedures), and all the information in this chapter will be used in the following chapters to build database applications.

So far, you’ve learned how to extract data from a database. In the following chapter, you’ll learn how to move this information from the server (the computer running SQL Server) to the client (the machine on which your application is running), how to store the information and process it on the client, and how to update the database.

Chapter 21

Building Database Applications with ADO.NET

In this chapter, we’re going to explore the basics of database applications. The database applications you build with VB.NET are client-server applications. The data resides in a database, which is installed on one of the computers on the network. To test the examples of this section, you will most likely use a copy of SQL Server installed on the same machine you use for development. In an actual production environment, your application will be installed on many clients, and all of the clients will be accessing the same database, installed on the server. The server knows how to access the data very efficiently, and that’s all it does. Presenting the data to the user and/or processing the data is your application’s responsibility. The server is the machine on which SQL Server is running. The machines on which the application is running are the clients.

The client-server model is a very efficient one because it allows you to share the computational load among multiple computers and each computer does what it can do best. The client computer gets data, presents them to the user, optionally processes them, and sends them back to the server. The server can focus on moving data out of and into the database. The type of client described here is called rich client, because it can use advanced controls to present the data to the user. It’s a workstation running Windows applications, which can process the data in many ways. For example, it can convert the data read from the database into elaborate graphical representations. There’s absolutely no reason to pass the task of processing the data to the server.

The client-server architecture a two-tier architecture. The programs running on the client make up the presentation tier; the database server is the data tier. Of course, you’ve all read that ADO.NET is a great tool for three-tier, or multitier, applications. So, what’s the third tier? Let’s consider for a moment an application that runs on the Web—an online store, for example. The client is the browser. This is the program that runs on each client and interacts with the user. Unlike a Windows application, the browser can’t deploy an elaborate user interface (you can’t place any of the Windows controls on a Web page); you’re limited to the HTML controls. This type of client is called thin client, because it has limited processing capabilities. The browser must receive HTML pages and render them on the monitor. The HTML page may contain scripts too, but even so you can’t duplicate the functionality of a Windows form on a Web page. In other words, you can’t pull data from the database, download them to the client, and process

926 Chapter 21 BUILDING DATABASE APPLICATIONS WITH ADO.NET

them there. If you want to convert the numeric data retrieved from the database into charts, you must create the pages with the graphs and download them to the client, where they can be rendered by the browser.

The processing of the data takes place on the Web server. The clients on the Web don’t see the database server directly. Instead, they contact a program running on the Web server, which in turns contacts the database to retrieve the requested data, format them in a way the browser can understand them, and then send the HTML page to the client. The programs running on the Web server that service the requests made by the clients form the third tier, and a Web application is the most familiar example of the three-tier architecture. The three-tier architecture is the evolution of the client-server model.

You can also introduce additional tiers to your applications. Let’s say your application records orders made over the Web. When the user places an order, the application running on the Web server may have to contact the server of a shipping company to get a quote on the shipping cost and add it to the total cost of the order. The programs on the shipper’s server form yet another tier of the application.

What makes VB.NET a great tool for multitier applications is that it uses XML to pass data between layers. XML is a text-based protocol that can describe any type of data, even images. By using the XML format, data are moved easily and reliably between layers, even between different operating systems and databases. Since you’re probably wondering about XML, what it can do for your applications and, especially, how well you must understand XML, let me simplify the picture a little. You can write database applications without ever seeing a line of XML code. ADO.NET uses XML to format the data and move them between the database and the client application (or any of the other tiers of the application). As you work with the objects of ADO.NET, you access data in their native format. XML is totally transparent to you.

The Architecture of ADO.NET

You already know how to retrieve data from a database with SQL statements and stored procedures. Now you’ll learn where the data are stored on the client computer and how to process them. We’ll get to the first few examples of database applications shortly, but first I would like to overview the architecture of ADO.NET. Once you have a good idea of the big picture and the motivation behind the design of ADO.NET, you’ll be able to better understand the objects of ADO.NET and how to use them.

ADO.NET is considered to be the evolution of ADO, but it doesn’t even resemble ADO. ADO was designed on the assumption that the client could maintain a connection to the database. When the Web wasn’t an issue, you could set up a connection to the database and request data over this connection, or update the database through the same connection. The client application was connected to the database at all times, and it could access any table at any time. In fact, this is how most database applications that run on local area networks are written today.

As programmers were looking for ways to access their databases over the Web, they realized that they couldn’t write applications that maintained their own connection to the database. They still used ADO, but they were using ADO in a disconnected mode: they wrote code to read data from the database, move them to the client, and close the connection to the database. The processing of the data took place on the client. To update the database, programmers had to establish a new connection, send

THE ARCHITECTURE OF ADO.NET 927

the modified data back to the server to update the tables of the database, and then close the connection again. Microsoft kept adding features to ADO to enhance the support of disconnected sets of data.

Clearly, there was a need for a different programming paradigm, one that would completely decouple the server from the client. This new paradigm was implemented with ADO.NET, which uses a disconnected architecture. The client application requests the data, which are downloaded to the client computer and stored locally. The client is your application that uses a database over the company’s network, or a Web application that connects to a Web server through any connection, from dial-up to T1. Even if you have a fast connection, ADO.NET doesn’t allow you to maintain a connection to the database and access it directly. Instead, you’re required to retrieve the data you need to the client and work with them there.

You know how to request the data you’re interested in. All you need is a structure that will hold the data. This structure is an object called a DataSet. The DataSet is a cache for your data, and it looks just like the database. You can edit the data in the DataSet, add new data, even combine the data you retrieved from your database with data from another database. It is possible (but certainly not recommended) to download all the tables to the client and work with a complete copy of the database. Everything you do the DataSet is local to the client and doesn’t affect the tables in the database. When you’re ready to update the underlying tables in the database, you establish a new connection, send the modified data, and close the connection again.

The DataSet is at the core of ADO.NET, because everything takes place in the DataSet. With ADO, there was a similar object, the Recordset object, where you could store a table or the result of a query and process it locally. The DataSet is far more than a Recordset: it’s a miniature database, made up of tables and relations between them. Let’s say you want to work with the invoices issued last month. The data you need are some rows of the Customers table (the customers that placed one or more orders in this period), some rows of the Orders table (the orders placed in the same period), and some rows of the Order Details table (the details that correspond to the

selected orders). Chances are you don’t need all the columns of these tables either. So you can specify, with SQL statements or stored procedures, the data you need and bring them into a DataSet on the client. The data will end up in three different tables in the DataSet, and you can establish relations between tables. In essence, you’re working with a subset of the database. You can review the data, edit them, do anything you would do if you were working directly against the database. The DataSet can impose the same constraints and enforce referential integrity between its tables. After you’re done processing the data, the DataSet knows how to move the changes back to the data- base—after all, they have the same structure.

While the data is in the DataSet, other users can add new rows to the tables of the database, even edit some of the rows you have copied into the DataSet. Unfortunately, there’s no way for you to know in advance that one of the customer rows in a local DataSet is no longer the same as the original row in the database. You will only find out when you attempt to update the database. As a result, this architecture is not ideal for applications like flight reservations. If you need this type of immediate access to the database, you should request data as you need them and update the database immediately. These types of applications are quite uncommon. ADO.NET is a great architecture for typical applications most of us are faced with on a daily basis, and it’s especially well suited for the Web. However, the current version of ADO.NET doesn’t address all the issues. It’s very likely that the next version of ADO.NET will also support connected DataSets. If not, there will be applications that ADO.NET can’t handle.