Chapter 6. Database Reuse

In Chapter 5, we discussed how to use code reuse mechanisms to build versatile form-creation and form-validation classes. In this chapter, we will look at how to build reusable database classes. As with the previous chapter, we will begin by examining database usage from a high level and look at how to accomplish various database-related tasks using standard, procedural code. Finally, we’ll convert these various procedural scripts into a robust set of classes, prime for reuse!

I think you’ll find the code presented and the topics discussed in this chapter to be extremely applicable. Database access is common among ASP web sites, and any steps that can be taken to reduce the time needed to create new database interface pages are steps in the right direction. However, presenting such a large and advanced application requires a great deal of time and explanation. This chapter is, by far, the longest in this book. It will most likely take you a long while to work through this chapter. If you stick with it, though, your fortitude will pay dividends, since the application presented in this chapter is very useful in the real world.

It is assumed that you are knowledgeable in relational database design and theory. If you are unfamiliar with the SQL syntax, or have never created a relational data model, it is strongly suggested that you become more familiar with these topics before beginning on this chapter.

Examining Database Usage

As discussed in Chapter 5, there are a number of typical form interfaces. One interface used often is the administration pages interface. In this interface, a superuser is able to add, edit, and remove records from a particular database table. With this interface, there is great room for reuse, since all of the administration pages follow a particular formula:

  • Provide a list of all the editable database tables. Each database table name should be a hyperlink to an administration page for that particular table.

  • On each table’s specific administration page, there should be three hyperlinked options: “Insert a New Record,” “Edit an Existing Record,” and “Delete an Existing Record.”

    • In the “Insert a New Record” page, the user should be presented with a form that contains form elements for each of the columns in the table. Once the form is filled out and submitted, a new record should be added to the table with the values entered by the user.

    • In the “Edit an Existing Record” page, the user should be able to select an existing record in the table. Upon selecting an existing record, the user should be taken to a page that contains a form similar to the form in the “Insert a New Record” page. The only difference is the form fields should have the existing record’s information entered into the various form fields. When the user has made changes to the record’s data and has submitted the form, the specified record should be updated with the new values.

    • In the “Delete an Existing Record” page, the user should be able to select an existing record to delete.

The administration page interface lends itself well to reuse since a number of similar steps need to be repeated for each database table’s administration page. The steps for creating an administration page for a specific table include:

  1. Create a web page with a form that contains a form element for each of the table’s columns. This is the form the user will visit when they choose “Insert a New Record.”

  2. Create a form-processing script for the form in Step 1 that will add the new record to the table.

  3. Create a web page that lists all of the existing records for the user to choose from when they want to edit an existing record.

  4. Create a web page that displays a form that contains a form element for each of the table’s columns. The values of these form elements are identical to the values of the record selected by the user in Step 3.

  5. Create a form-processing script for the form created in Step 4. This form-processing script is responsible for updating an existing database record (selected through the form in Step 3) with the values entered into the form in Step 4.

  6. Create a web page that lists all of the existing records for the user to choose from when they want to delete an existing record.

  7. Create a form-processing script for the form in Step 6 that will delete the record selected by the user.

These seven steps must be repeated for every table in the database that requires an administration page! Clearly, if any of these steps can be reused for each table’s administration page, we will save ourselves considerable time. In this chapter, we will examine how to turn each of the above steps into reusable code. For some of the steps, a brief discussion will be presented on potential methods that could be used to make the step highly reusable. For other steps, a more in-depth analysis will occur, accompanied by code examples. These topics are discussed in detail in the next section.

Tip

You can probably see that some of these steps can be combined, reducing the overall number of steps needed for each table’s administration page. For example, the forms in Step 3 and Step 6 could share a single web page, as could the forms in Step 1 and Step 4.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.118.126.241