Table of Contents
| Introduction | 1 |
| Ch. 1 | Getting Started with ASP.NET | 9 |
| Ch. 2 | Anatomy of an ASP.NET | 45 |
| Ch. 3 | Server Controls and Variables | 69 |
| Ch. 4 | Control Structures and Procedural Programming | 121 |
| Ch. 5 | Jumping Structures - Subroutines and Functions | 161 |
| Ch. 6 | Event-Driven Programming and Postback | 191 |
| Ch. 7 | Objects | 213 |
| Ch. 8 | Reading From Databases | 249 |
| Ch. 9 | Advanced Data Handling | 287 |
| Ch. 10 | ASP.NET Server Controls | 315 |
| Ch. 11 | Users and Applications | 383 |
| Ch. 12 | Reusable Code for ASP.NET | 435 |
| Ch. 13 | .NET Assemblies and Custom Controls | 467 |
| Ch. 14 | Debugging and Error Handling | 513 |
| Ch. 15 | Configuring and Optimization | 569 |
| Ch. 16 | Web Services | 603 |
| Ch. 17 | ASP.NET Security | 651 |
| App. A: Exercise Answers | 685 |
| App. B | Web Matrix Quick Start | 747 |
| App. C | The Wrox United Database | 763 |
| App. D | Web Application Development using Visual Studio .NET | 775 |
| App. E | Installing and Configuring IIS | 819 |
| Index | 841 |
Read a Sample Chapter
Beginning ASP.NET 1.1 with VB.NET 2003
By Chris Ullman John Kauffman Chris Hart David Sussman John Wiley & Sons
ISBN: 0-7645-5707-6
Chapter One
Reading From Databases So far in this book you've learnt a lot about programming, and seen those techniques in use in a variety of Web pages. Now it's time to turn our attention to one of the most important topics of building Web sites - data. Whatever the type of site you aim to build, data plays an important part. From a personal site (perhaps a vacation diary or a photo album), to a corporate e-commerce site, data is key.
There are many ways in which data can be stored, but most sites will probably use a database. So in this chapter we're going to look at data stored in databases, and show how easily it can be used on Web pages. For this we are going to use ADO.NET, which is the data access technology that comes as part of the .NET Framework.
If the thought of databases sounds complex and scary, don't worry. We're going to show you just how easy this can be. In particular, we'll be looking at:
Basics of databases and how they work
Creating simple data pages using Web Matrix
Different ADO.NET classes used for fetching data
Basics of ADO.NET and how it fetches data
Using Web Matrix to simplify developing data access pages
Before we can head into these topics though, we need a little theory.
Understanding Databases
Understanding some basics about databases is crucial to using data in your pages. You don't need to be a database expert, but there are certain things you will need to know in order to work with data in .NET. For a start, you need to understand how data is stored. All types of data on a computer are stored in files of some sort. Text files, for example, are simple files and just contain the plain text. Spreadsheets, on the other hand, are complex files containing not only the entered text and numbers, but also details about the data, such as what the columns contain, how they are formatted, and so on.
Databases also fall into the category of complex files. When using Microsoft Access, you have an MDB file - this is a database file, but from the file itself you can't tell anything about the data inside. You need some way to get to the data, either using something such as Microsoft Access itself, or as we are going to do, using the .NET data classes.
Before you can access the data, you need to know how it is stored internally.
Tables
Within a database, data is stored in tables - these are the key to all databases. A table is like a spreadsheet, with rows and columns. You generally have multiple tables for multiple things - each distinct type of data is stored separately, and tables are often linked together.
Let's look at an example to make it easier to visualize. Consider an ordering system, for example, where you store details of customers and the goods they've ordered. The following table shows rows of customer orders, with columns (or fields as they are sometimes called in database terms) for each piece of order information:
Customer Address Order Date Order Item Quantity Item Cost
John 15 High Street 01/07/2003 Widget 10 3.50 Brumingham England
John 15 High Street 01/07/2003 Doodad 5 2.95 Brumingham England
John 15 High Street 01/08/2003 Thingy 1 15.98 Brumingham England
Chris 25 Easterly Way 01/08/2003 Widget 1 3.50 Cradiff Wales
Dave 2 Middle Lane 01/09/2003 Doodad 2 2.95 Oxborough England
Dave 3 Middle Lane 01/09/2003 Thingamajig 1 8.50 Oxborough England
This is the sort of thing you'd see in a spreadsheet, but there are a couple of big problems with this. For a start, we have repeated information. John, for example, has his address shown thrice. What happens if he moves house? You'd have to change the address everywhere it occurs. Dave has two addresses, but notice they are slightly different. Which one is correct? Are neither correct?
To get around these problems we use a process called Normalization.
Normalization
Normalization is the process of separating repeated information into separate tables. There are whole books dedicated to database design, but we only need to look at the simplest case.
A good beginner book on database design is Database Design for Mere Mortals: A Hands On Guide to Relational Database Design, 2nd Edition (ISBN: 0-201-75284-0).
What we need to do is split the previous table into three tables, one for each unique piece of information - Customers, Orders, and OrderDetails. To link the three new tables together, we create ID columns that uniquely identify each row. For example, we could create a column called CustomerID in the Customers table. To link the Customers table to the Orders table we also add this CustomerID to the Orders table. Let's take a look at our tables now.
The Customers table is as follows:
CustomerID Customer Address
1 John 15 High Street BruminghamEngland
2 Chris 25 Easterly Way Cradiff Wales
3 Dave 2 Middle Lane OxboroughEngland
The Orders table is as follows:
OrderID CustomerID OrderDate
1 1 01/07/2003
2 1 01/08/2003
3 2 01/08/2003
4 3 01/09/2003
The OrderDetails table is as follows:
OrderDetailsID OrderID Order Item Quantity Item Cost
1 1 Widget 10 3.50
2 1 Doodad 5 2.95
3 2 Thingy 1 15.98
4 3 Widget 1 3.50
5 4 Doodad 2 2.95
6 4 Thingamajig 1 8.50
We now have three tables that can be linked together by their ID fields as shown in Figure 8-1:
We now have links between the tables. The CustomerID field in the Orders table is used to identify which customer the order is for. Similarly, the OrderID field in the OrderDetails table identifies which order a particular order line belongs to.
The unique key in a table is defined as its Primary Key - it's what uniquely defines a row. When used in another table it is called the Foreign Key, so called because it's a key, but one to a foreign table. The foreign key is simply a column that is the primary key in another table. Because the values of the primary key and the foreign key will be the same, we can use them to link the tables together. This linking of the tables is done in Structured Query Language (SQL), usually as a query or a stored procedure.
SQL and Stored Procedures
Queries are the way in which we deal with data in a database, either to extract data or to manipulate it. We can use an SQL statement or a stored procedure, which is an SQL statement wrapped to provide a simple name. It's worth to note that a stored procedure is actually more than just wrapping an SQL statement in a name, but that's a good enough description for what we need.
If you remember, in Chapter 5 when we looked at functions, we had a function name encapsulating some code statements. Think of a stored procedure in a similar way - it wraps a set of SQL statements, allowing us to use the name of the stored procedure to run those SQL statements. We're not going to focus much on this topic as it's outside the scope of this book.
To learn more about SQL, read SQL for Dummies (ISBN 0-7645-4075-0) by John Wiley & Sons.
Here are a few reasons why you should always use stored procedures instead of direct SQL:
Security: Using the .NET data classes with stored procedures protects you against certain forms of hacking.
Speed: Stored procedures are optimised the first time they are called, and then the optimised code is used in subsequent calls.
Separation: It keeps the SQL separate from your code.
During the rest of this book we'll actually be using a mixture of SQL and stored procedures, for the simple reason that sometimes it's easier to use SQL in the context of an example. Remember, our main focus is ASP.NET. We'll be using Microsoft Access for the samples, and although Access doesn't support stored procedures, its use of stored queries is equivalent.
Let's get on with some examples.
The Web Matrix Data Explorer
You've already seen how powerful Web Matrix is for creating Web pages, and this power extends to working with data. Where you've used the Workspace Explorer in the top right hand corner of Web Matrix to work with files, you can use the Data Explorer to work with data. This provides ways of creating databases, connecting to existing ones, and working with tables and queries. Let's give this a go.
Try It Out Connecting to a Database
1. Select the Data Explorer tab, and click the Add Database Connection button - the one that's second in from the right, and will be the only one highlighted, as shown in Figure 8-2, if you haven't already got a database connection open:
2. Select Access Database from the window that appears and press OK.
3. Enter the following into the Data File text area (we'll use a central location for the database, so that we can reuse it later in the book):
C:\BegASPNET11\data\Northwind.mdb
4. Press OK to connect to the database. This is the Northwind database, one of the sample databases that ships with Microsoft Access.
5. Figure 8-3 shows the tables contained in this database:
You can double-click on these to open the table, and see and change the data. One thing you might notice is that you don't see any queries - that's because Web Matrix doesn't support queries in Access. When connecting to SQL Server, you'll see the stored procedures - you can even create and edit them - but for Access, you are limited to tables only.
How It Works
There's nothing really to explain about how it works. What we are doing is simply creating a connection to a database that Web Matrix can use. This isn't required for ASP.NET to fetch data from databases, but Web Matrix has some great ways to generate code for you, so you don't have to do as much coding.
Creating Data Pages
Pages that display data can be created in a number of ways, and let's first look at the three ways that Web Matrix uses to save you coding. This is the quickest way to get data into your pages and saves a great deal of time. However, what it might not do is give you the knowledge to access databases without using Web Matrix. After we've seen the easy ways, we'll look at the .NET classes that deal with data. This way you'll have techniques to work with and without Web Matrix.
Displaying Data Using the Data Explorer
You've already seen how easy connecting to a database is using the Data Explorer. Creating pages directly from this explorer is even easier - all you have to do is drag the table name and drop it onto a page. This will automatically create a connection on the page and a fully functional data grid. Let's give this a go.
Try It Out Creating a Grid
1. Create a new ASP.NET page called Grid1.aspx.
2. From the Data Explorer, drag the Suppliers table onto your empty page as shown in Figure 8-4:
3. Save the page and run it to see Figure 8-5:
Amazing! A sortable grid full of data and you didn't have to write even a single line of code!
How It Works
Its workings rely on two controls: the AccessDataSourceControl, which provides the connection to the database, and an MxDataGrid, which is a Web Matrix control (also covered in Chapter 10) that displays the data. Looking at the HTML view for these controls gives you a good idea of what they do.
Let's start with the AccessDataSourceControl:
The first thing to notice is the way the control is declared. You're used to seeing asp: at the beginning of controls, but not wmx:. This prefix is the namespace - remember in the previous chapter where we said that namespaces provide a separation between classes. In this case, these controls are part of Web Matrix, and have thus been given a different namespace from the standard server controls.
Apart from the id and runat, there are two other attributes that provide the details regarding which database to connect to and what data to fetch:
The SelectCommand defines the SQL that will return the required data - in this case, it's all rows and columns from the Suppliers table. This is the default since we dragged this table, but we can customize the SelectCommand to return only selected rows or columns.
The ConnectionString defines the OLEDB connection string. You only need to worry about the bit with the path of the database file - the Data Source bit (if you move the file, you'll need to change this). The other parts of the ConnectionString just define the type of database and some database specific features. You don't need to know about these specifically (they are fully documented in the .NET help files); just copy them if you ever need to use them again.
At this stage you have enough details to connect to a database and fetch data, but don't have any way to display it. For that we are going to use the MxDataGrid:
This seems complex but is actually very simple.
Continues...
Excerpted from Beginning ASP.NET 1.1 with VB.NET 2003 by Chris Ullman John Kauffman Chris Hart David Sussman 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...