Validating User Data Entry

You cannot assume that the application user will enter data into form fields as expected. In nearly every case, you will need to perform some field validation against every user entry field. The remaining question is where and when that validation occurs.

Client-side scripting languages, such as JavaScript and VBScript, have gained popularity for their ability to execute field validation code on the client side within the Web browser. This offers instant data validation as data is entered. Events that validate user entry trigger the moment that focus switches from one form field to the next . The only problem is that a variety of Web browser providers implement their scripting support differently, almost ensuring that script code targeted for one browser will not work in another.

The question then becomes, why must field validation be performed on the client side? When it works properly, it is nice to have that instant field-level validation. However, the client side might not be the right place for that. This is where postbacks are helpful.

Validating Data in Web Form Postbacks

Web form postbacks validate field data as it is entered ”on the server side. You can enable form field postback by setting a control's AutoPostBack property to true. When enabled, any change in a control's value results in a postback event handled by the Page_Load method.

The benefit is that client-side scripting does not need to target one or more Web browser platforms because it is completely avoided. Although validation is occurring on the server, it appears to the user that it is occurring locally and presents the appearance of a more interactive user interface.

The cost is performance and flexibility. If a trip to the Web server is necessary for each field to be validated, then a dozen validated fields means a dozen requests from the server. This additional processing load to the server did not exist before. Also, the busier the server becomes, the slower the page will appear to the application user. Also, because the Page_Load method handles the postbacks, it is important to separate the logic that initializes the page from the logic that validates a form field; otherwise , page initialization logic might be called in every case. The IsPostBack is an important property to check while handling page loads:

 private void Page_Load(object sender, System.EventArgs e) {     if( IsPostBack )     {         //perform page validation logic         }         else         {              //perform page initialization logic         }         return; }

Although Web form postbacks keep validation code on the server, where it should be, it is still not in the best place. You should place validation code within the business object that internally represents the data.

Validating Data in Business Objects

The optimal location for field validation logic is within the business objects that are filled in response to user input. Rather than validate field by field, all validation should occur at once when the user submits the page for processing. The page's submit handler should instantiate a new business object, populate it with the user-supplied data, and then invoke its Validate method. Listing 7-12 outlines this process by implementing an event handler for the OK button in the new Issue form. If any error messages are generated, then they are displayed within a Label control in red. Otherwise, the data is committed and the user is redirected to another page.

Listing 7-12: Web Form Values Assigned to a Matching Business Object

 private void btnOK_Click(object sender, System.EventArgs e) {     Issue objIssue = new Issue();     //assign business object properties     objIssue.Description = Issue_Description.Text;     objIssue.EntryDate = Issue_EntryDate.Text;     objIssue.PriorityID = Issue_PriorityID.SelectedValue;     objIssue.StatusID = Issue_StatusID.SelectedValue;     objIssue.Summary = Issue_Summary.Text;     objIssue.TypeID = Issue_TypeID.SelectedValue;     //validate business object     lblError.Text = objIssue.Validate();     if( lblError.Text.Length == 0 )         Response.Redirect( "IssueSummary.aspx", true );     return; }

The business object's Validate method, outlined in Listing 7-13, performs field-by-field validation of its properties. A string that appends all discovered errors is returned to the caller.

Listing 7-13: The Business Object Implementing a Validate Method That Checks the Values

 public string Validate() {     string strErrorMessage = "";     if( _TypeID == 0 )         strErrorMessage += "Issue Type is not set. ";     if( _StatusID == 0 )         strErrorMessage += "Issue Status is not set. ";     if( _PriorityID == 0 )         strErrorMessage += "Issue Priority is not set. ";     if( _Summary.Length == 0 )         strErrorMessage += "Issue Summary has no value. ";     if( _Summary.Length > 64 )         strErrorMessage += "Issue Summary is too long. ";     if( _Description.Length == 0 )         strErrorMessage += "Issue Description has no value. ";     if( _Description.Length > 64 )         strErrorMessage += "Issue Description is too long. ";     return strErrorMessage; }

The reason for placing validation logic within the business object is to minimize errors and maximize reuse. Because the business object becomes a central location for validating data, multiple Web forms do not need to implement it separately. This reduces errors in that all pages capturing this data will apply the same validation logic. Also, because validation is performed in the business logic and not the Web form code-behind page, it can be reused by other non-Web applications targeting the desktop and mobile platforms.