iLab Overview

Scenario/Summary

In this week’s iLab, we refactor our web application and add a secure login feature.

Part I: Refactoring
As applications grow and change with added features and fixed bugs, they can become unwieldy and very difficult to maintain. When an application is difficult to maintain, even a small change to the app can result in hard-to-find bugs. The original design of the application may no longer support the features and functionality present in the current application version.

The solution to this situation is refactoring the application code to better distribute the workload among the classes in the application. Refactoring does not change the external functionality of software; it changes the internal structure by reorganizing it. After refactoring our application, it should look the same to users but execute more efficiently and be easier to maintain.

pgCheckOut.aspx.cs has become fairly large, making it difficult to maintain. The reason for this is that we have the pgCheckOut class doing much of the work that belongs in the business layer and data layer. For this week, the goals of our refactoring are as follows.

Correctly distributing application functionality
The presentation layer ( pgCheckOut) manages user interaction through the ASP form. It makes requests of the business layer for data to populate form fields, responds to button presses, and sends form data to the business layer for processing.
The business layer ( clsBusinessLayer) validates data, catches exceptions, and corrects them if possible. This layer handles communication between our application and others (through an XML file) and retrieves data from the data layer.
The data layer ( clsDataLayer) interacts with database and responds to requests form the business layer. When we are finished with our refactoring, pgCheckOut.aspx.cs should not need any knowledge or interaction with the data layer (clsDataLayer.cs)
Replace repeated or duplicate code with methods to improve maintainability
We want to replace code that is duplicated in several places with either a method when it is a sequence of statements, or a data field when it is a reused piece of data, such as the data directory’s Server.MapPath. We already reduce duplication on our forms by using master pages. This step allows us to reduce duplication in our code.

Part II: Secure Login
Because our application manages customer information, we should provide a secure login so that only authorized users can view and manipulate customer information. Our secure login page accepts a username and password. If the same user fails to correctly enter his or her password three times, that user’s account is locked and the person must contact the system admin to unlock it. If there is a total of six failed login attempts during the session, no matter the user, the application locks by hiding the login/submit button.

Here is an outline of this lab:

PART 0: Prepare Your Project

Start your project as a copy of the Week 4 iLab
PART I: STEP A: Move the GetAllCustomers Functionality to the Business Layer

Add a method to clsBusinessLayer.cs and modify a method in pgCheckOut.aspx.cs.
PART I: STEP B: Move Update and Insert Customer Functionality to the Business Layer

Add two methods to clsBusinessLayer.cs, add a new method to pgCheckOut.aspx.cs, and modify two other methods in pgCheckOut.aspx.cs.
PART I: STEP C: Move Retrieving a Single Customer’s Data to the Business Layer

Add a method to clsBusinessLayer.cs and modify a method in pgCheckOut.aspx.cs.
PART II: STEP D: Data Layer Functionality: Validating and Locking Users

Add two methods to clsDataLayer.cs.
PART II: STEP E: Implement the Business Layer Functionality to Verify User Credentials

Add one method to clsBusinessLayer.cs.
PART II: STEP F: Create the Login Form

Create a form, user the site master page and add controls.
PART II: STEP G: Implement Login Functionality

Validate user credentials and redirect to pgCheckOut.aspx.
PART II: STEP H: Harden Your Application (Optional)

Optionally add features to obscure passwords and prevent SQL injection.
PART II: STEP I: Finalize the iLab

Deliverables

NOTE
Submit your assignment to the Dropbox, located at the top of this page. For instructions on how to use the Dropbox, read these step-by-step instructions.

(See the Syllabus section “Due Dates for Assignments & Exams” for due dates.)

Please zip and submit the entire web project folder to the assignment Dropbox.