Table of Contents
Introduction.
Chapter 1. ASP.NET and Data.
Chapter 2. Connecting to a Data Source.
Chapter 3. Displaying Data Using the DataReader.
Chapter 4. DataSets.
Chapter 5. Handling Errors and Exceptions.
Chapter 6. Creating Records.
Chapter 7. Using Stored Procedures.
Chapter 8. Updating Data.
Chapter 9. Handling Data in Components.
Chapter 10. Performance.
Appendix A. Setting Your Server Up.
Appendix B. ADO.NET Object Model.
Appendix C. Notes on the "Flavors" of SQL.
Index.
Read a Sample Chapter
Beginning ASP.NET Databases Using VB.NET
By John Kauffman Fabio Claudio Ferracchiati Brian Matsik Eric N. Mintz Jan D. Narkiewicz Kent Tegels Donald Xie John West Jesudas Chinnathampi James Greenwood John Wiley & Sons
ISBN: 0-7645-4375-X
Chapter One
Displaying Data on the Web When the Web first appeared, people had to find a metaphor for how information should be presented on it. If you took a sample of web sites from that period, the content largely was based around what you'd find in traditional media such as books, magazines, and newspapers. This led to the Web serving the same purpose as those other formats: it provided a snapshot of information as it stood at the time the pages were created. Of course, there was nothing wrong with that, but it placed restrictions on what the Web could reasonably be used for.
Over time, the technologies powering the Web have matured, and it has changed from only being able to provide static sites, to providing dynamic applications as well. These applications invite their users to make choices about the information they're interested in, providing a customized user experience that can be modified in real time.
The key to these applications is the data they contain. Regardless of what it is - it could be a product catalogue, or a set of customer details, or a document repository - it's the data that makes them dynamic. In the past, providing data over the Web has been a harder task than providing it through traditional desktop applications, due both to the development tools and functionality available, and the nature of the Web itself, where users are far removed from the applications and data. Over time, and in particular (from our point of view) with the introduction of Microsoft's .NET Framework, this situation has been improved. Web application developers are now on a more equal footing with their desktop-developing counterparts.
In this first chapter, we'll provide a broad introduction to the topic of data-driven web sites, and how they are implemented in ASP.NET. It starts with a discussion of the advantages and disadvantages of data-driven sites, and then moves on to examine the sources that such data can come from. After that, we'll look at the .NET Framework's data access strategy of choice - ADO.NET - including its architecture, its classes, and how it fits into the structure of data-driven applications. We'll finish by covering the installation of a database server that we'll use throughout this book.
Pros and Cons of Data-Driven Web Sites
Some of the advantages of having a data-driven system are immediately apparent, but there are others that are less tangible and not so readily evident. Naturally enough, there are also reasons why you might not want to attach a web site to a database. In this section, we'll examine the benefits and the drawbacks of creating a web site that's based around a data source.
Advantages
There are many secondary benefits of making a web site data-driven, such as the ability to reuse portions of functionality in other projects, and being able to share common pieces of information across systems - these tend to kick in when you start to work on your second or your third web application. Here, we're going to look at some of the advantages that can start to accrue as soon as you make the decision to create a data-driven site:
Quality and timeliness of content. The most immediate advantages to making a site data-driven are the speed with which new information can be presented on the Web, and the controls that can be put in place to guarantee the quality of this information. Rather than having to get a web designer to create a page containing the information, and then get it uploaded again every time a price changes or a new product is added, a tool can be created that enables the instant publishing of new or updated information simply by modifying the database. This is one of the key benefits of the Web over traditional media - the ability to view information in real time, rather seeing than a snapshot of old data. By enforcing rules on who can add and amend data, how it is checked, and whether it is approved, data can be verified prior to being published in a much more rigorous manner, ensuring that the user only sees accurate details.
Functionality. The other main benefit of storing all of the data required for a site in a database is that of improved functionality in terms of the actions that the user can perform on the system. Rather than producing 'catalogues', which (like this book) just have an index and a contents table as a means of searching, forms can be created that allow the user to specify what is being looked for, and have the system scour the database for that information. A great example of this is a search engine. Without a database, such a site would present only a manual categorization of other web sites, with a huge structure of pages that you could (try to) navigate between.
Maintenance. With the data for a site stored in a separate location from the presentation code, there is no longer a need to maintain static links in HTML files between related sections of a site, forcing you to reapply formatting and menu structures to hundreds of pages each time the site is redesigned. In a data-driven system, web pages are typically templates that act for entire classes of pages, rather than having one page for each piece of information.
As an example of this, you could imagine the on-screen appearance of a page that displays the details of a product for sale. Rather than this being a separate HTML page, in a data-driven system there would be one page containing fields and tables that could be populated with data regarding any product. This means that there is far less to do each time a redesign is implemented. Similarly, as the relationship between different pieces of information can be stored in the database (rather than hard-coded in the pages), links to related products and other information can be generated on the fly.
Disadvantages
Although there are many advantages to making a web site data-driven, some of them come at a price, and a data-driven site is not always the right solution to your problem. There are several hurdles that must be overcome in order to provide a richer experience to the end user, and it's important that you consider them before taking the plunge:
Development. A large number of web sites that are now data-driven started out being static, and there are still many static sites being created to this day. The nature of the content you want to present is not always suited to a data-driven site, and the creation of a data-driven system requires extra time and skills, resulting in a product that is more complex, and (inevitably) more prone to errors. These costs have to be weighed up against the advantages that such a system provides.
Performance. The performance of data-driven web sites is an issue that crops up regularly. If a site is entirely static, then there are no constraints on the way the system is organized, or on how it can expand to cater for higher volumes of users. The simplest way to increase performance is to buy a faster processor and more memory. When that stops being viable, multiple versions of the site can be created, and users redirected to whichever one is under least load. This can continue in a linear fashion, with the same increase in performance each time a new web server is added.
With a data-driven site, this is not the case, because the entire system is dependent upon one resource: the database. If it's not carefully designed, the database can create a bottleneck in the system, whereby the rest of the application is held up while it waits for information to be retrieved. Removing this bottleneck is a difficult problem to solve - having multiple synchronized databases is one of the few real solutions, but it can prove very expensive, and the overheads involved in this synchronization are significant.
Cost. In addition to the technical considerations mentioned above, there are also associated commercial issues. For a relatively static site, the time required to create a database and write the code to access it may be longer than it would take just to edit some HTML pages. Also, enterprise-class database systems are themselves expensive. Considering Microsoft's data storage solutions alone, it's well known that producing a solution using SQL Server (Microsoft's enterprise-level database server) provides many benefits over Access (its desktop database), such as higher performance and better support for industry standards, but comes with a price tag to match.
Data Sources
So: you've already considered some or all of the issues in the above lists, and you're still with us, which means that it's reasonable to assume you want to write a data-driven web application. The first question that needs to be answered, then, is where the information that will eventually end up on the user's screen is going to come from. Depending on factors such as the type of data, what operations are to be performed on the data, and the amount of use that is going to be made of the system, there are a multitude of options available. This section describes the reasons for and against using three of the most common data source types, along with an overview of the other types available.
Databases
When you start thinking about data sources, the most obvious one that springs to mind is the database, which will generally provide the most reliable, scaleable, and secure option for data storage. When you're dealing with large amounts of data, databases also offer the best performance. However, the very fact that other solutions exist is a sure indication that in some circumstances, they're not the best choice.
In general, databases are designed to store large amounts of data in a manner that allows arbitrary quantities of data to be retrieved in arbitrary order. For small collections of data, such as a set of contact details, the time and other costs involved in creating and accessing a database might outweigh the benefits that databases provide.
We'll have much more to say about the structure of databases in the next chapter, but as a quick example, wanting to store some information about a company employee in a database might move us to create a table called Employee that can contain the same pieces of data about a number of employees. Such information could include their EmployeeID (number), LastName, FirstName, BirthDate, and Country:
Employee EmployeeID LastName FirstName BirthDate Country
Throughout this chapter, comparisons and demonstrations will be made of how data can be stored and represented. For consistency, the same example is used throughout: that of storing details about the employees in an organization.
One thing to note when we display a database diagram, compared to the diagrams of other data sources, is that it's based on a model of the information being stored, rather than examples of the data. The way in which databases actually hold information is largely hidden from the outside world, leaving us to depict concepts rather than actual data items.
Text Files
At the opposite end of the scale from using databases to store information for a web site is the use of text files. Although text files can store information in almost any conceivable format, they are generally used for storing a set of data, one item on each line. If we were to capture the employee information detailed above, we could store the LastName, FirstName, BirthDate, and Country of two employees in a text file as follows:
Smith, John, 05-04-1979, UK Bloggs, Joe, 29-09-1981, US
For simple information such as this, a text file provides an easy way of reading and writing data. If the data to be stored has more structure, however, it becomes far more time consuming. For example, it could be the case that each of these employees has placed an order for some office supplies. Rather than adding all of that information to the text file as well, it would be better to hold it separately, and then define relationships between the two sets of data.
When the data starts to gain 'structure' in this manner, a method of giving the file itself some structure must be found, and a way of retrieving it and representing it in memory must also implemented. One way of doing this is through the use of XML.
XML
In some ways, XML documents can be thought of as a stepping-stone between text files and databases; they store data using text files, but use a hierarchical and relational format that is both extensible and self-describing, providing a number of the benefits of a database system. Before we go any further in explaining the use of XML as a data source, a sample fragment of an XML document is shown below:
As you can see, the same information is being stored as in the text file, but there's also an indication of the nature of that information. You know that 29-09-1981 is the BirthDate of Joe Bloggs, because the data says so. Another benefit of XML is that it can contain multiple types of information in one document; a fragment like the one below could be inserted after : Staples Pencils Biros Erasers
Using the comprehensive functionality that's built into the XML-handling support provided by the .NET Framework (and other platforms), retrieving and manipulating the orders separately from the employees can be accomplished quite easily. This makes it possible to specify an order from the list for each employee by storing the ID of each order as part of the employee's details:
XML is a powerful way of representing information, but in some circumstances performance can be a problem: updating and retrieving data from XML can be a time-consuming process. This is rarely an issue when a few users are accessing a small amount of data, but if there's a lot of data (or a lot of users) it can sometimes become one.
Continues...
Excerpted from Beginning ASP.NET Databases Using VB.NET by John Kauffman Fabio Claudio Ferracchiati Brian Matsik Eric N. Mintz Jan D. Narkiewicz Kent Tegels Donald Xie John West Jesudas Chinnathampi James Greenwood Excerpted by permission.
All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.
loading...