nowing whether a group of form fields have changed and which fields have changed can be beneficial in many ASP.NET Web applications. ASP.NET triggers a "value change" event at the server side for each server control for which the client changed the value upon postback.
Many applications contain groups of related form fields, often correlated with each other and typically corresponding to member data in a business object. Thus developers often need to check if such a group of form fields has changed as a whole.
Unfortunately, the .NET Framework (1.x, 2.0) doesn't offer an effective solution. This article will present an elegant technique to solve this problem and it can even go further so that you can know which field has changed. Let me list a few of the benefits of this technique:
Installing and Compiling the Sample Code
- Provide a reliable server-side method to detect changes on form fields as a whole, letting you persist only changed groups of form data into the database, thus avoiding unnecessary database update via stored procedures or embedded SQL. In the worst case, the technique imposes a marginal overhead due to change-checking logic.
- You can build embedded UPDATE SQL statements on the fly to update only changed columns when form field values change and form data corresponds to columns in a table. Thus, this technique can reduce coding and possibly improve performance.
- You can update multiple table records or groups of form data in batches with one click of a button. Because this technique avoids unnecessary database updates, it doesn't degrade overall performance. More significantly, you can reduce page postbacks. In contrast, ASP.NET 2.0's support out of the box either updates all records with one button click or associates an update button with each record (typically seen in an iterative control such as Repeater or DataList, and so on).
I based the code in this article on the .NET Framework 1.1 and Visual Basic .NET; however you can easily port the code to either the .NET Framework 1.0 or 2.0 by recompiling it. The .zip
file contains two projects: The xControls
implements the logic to detect form data changes, and the DetectFormValueChange
is a small Web project for demo purposes. Copy the code into a virtual directory named DetectFormValueChange
and browse to the TestChange.aspx
Web Form to run the demo.
Developers might try to hook the value-change event handler for each server control, but that leads to tedious, messy code, and worsecode that's not reusable. To solve this problem, you'll use a technique called subclassing that extends the functionalities of server controls by supplying an interface, hooking up an event handler, etc. The resulting subclassed code is well-encapsulated and offers good reusability. You'll use three straightforward steps to implement this server-side technique.
- Identify server controls that can hold form data and extend them with a common interface property called FormGroup that lets you distinguish different groups of form fields.
- Hook up the value change event handler to save form data change information. When a form field value changes, this special handler executes and stores the change information for use in a later database query.
- Execute implementation logic to determine how change information of the form fields is stored and queried. The logic exists in static functions and is encapsulated in a separate class.