Chapter 6: Using the Validation Controls

We’ll expand the code inside this method in later chapters, but for the time being, you can rest assured that you’ve put the validation mechanism in place.

Summary

As we’ve seen, the validation controls available through ASP.NET are very powerful. This chapter explained how to validate required form fields with the

RequiredFieldValidator, compare form fields with the CompareValidator, check for a numeric range within form fields with the RangeValidator, provide a user with a summary of errors using the ValidationSummary control, check for email addresses with the RegularExpressionValidator, and perform your own custom validation with the CustomValidator.

In the next chapter, we’ll begin to introduce you to the challenges—and re- wards!—involved in working with databases. This is a skill you’ll almost certainly need when building any non-trivial real-world web application, so roll up your sleeves and let’s get into it!

250

Chapter 7: Database Design and Development

What is a Database?

Before we become mired in techno-speak, let’s take a step back to consider the project at hand—the Dorknozzle Intranet—and how it can benefit from a relational database. By the end of this book, our site will be able to do all sorts of things, but beside these bells and whistles, our company intranet will need to do one core job: keep track of the employees in our company. The employee directory we plan to build would be a sorry sight indeed without a list of employees!

So, how will we go about building that information into our site? Experience with static web design might lead you to create a web page named Employee Directory, which displayed a table or list of some kind, and to type in the details of each of the employees in the company. But, unless Dorknozzle is a very small company, a single page that contained all the details of every employee would be destined to become unusably large. Instead, you might only list the employees’ names, and link each to an individual profile page. Sure, this approach might mean there’s a bit of typing to do, but it’s the kind of job you can assign to the boss’s son on his summer internship.

Now, imagine that, a month or two down the track, Dorknozzle undergoes a corporate re-branding exercise (a bright idea undoubtedly proposed by the boss’s son one night at the dinner table), and the entire web site needs to be updated to match the “new look” of the company. By now, Dorknozzle Jr is back at school, and the mind-numbing job of manually updating each of the employee profile pages falls right in your lap. Lucky you!

Life would be a lot more pleasant if a database was added to the mix. A database is a collection of data organized within a framework that can be accessed by programs such as your SPINET web site. For example, you could have the Dorknozzle intranet site look into a database to find a list of employees that you want to display on the employee directory page.

Such a collection of data needs to be managed by some kind of software—that software is called a database server. The database server we’ll use in this book is SQL Server 2005 Express Edition, which is a free but very powerful database engine created by Microsoft. Other popular database server software products include Oracle, DB2, PostgreSQL, MySQL, and others.

In our Dorknozzle scenario, the employee records would be stored entirely in the database, which would provide two key advantages over the manual maintenance of a list of employees. First, instead of having to write an HTML file for

252

What is a Database?

each employee profile page, you could write a single ASP.NET web form that would fetch any employee’s details from the database and display them as a profile. This single form could be updated quite easily in the event of corporate re-branding or some other disaster. Second, adding an employee to the directory would be a simple matter of inserting a new record into the database. The web form would take care of the rest, automatically displaying the new employee profile along with the others when it fetched the list from the database.

As a bonus, since this slick, ultra-manageable system reduces the burden of data entry and maintenance, you could assign the boss’s son to clean the coffee machine in his spare time!

Let’s run with this example as we look at how data is stored in a database. A database is composed of one or more tables. For our employee database, we’d probably start with a table called Employees that would contain—you guessed it—a list of employees. Each table in a database has one or more columns (or fields). Each column holds a certain piece of information about each item in the table. In our example, the Employees table might have columns for the employees’ names, network usernames, and phone numbers. Each employee whose details were stored in this table would then be said to be a row (or record) in the table. These rows and columns would form a table that looks like the one shown in Figure 7.1.

Figure 7.1. Structure of a typical database table

Notice that, in addition to columns for the employees’ names, usernames, and telephone numbers, I included a column named Employee ID. As a matter of good design, a database table should always provide a way to identify each of its rows uniquely. In this particular case, you might consider using an existing piece of data as the unique identifier. After all, it’s unlikely that two employees would share the same network username. However, that’s something for our network administrator to worry about. Just in case he or she slips up somewhere along

253