Practical ASP.NET
Maintaining Data Integrity from the DataView
I finished last month's column, titled
Dynamically Setting Parameters, with a bit of philosophy around when to use the DataView and when to use the DataSource where the two controls share functionality.
Here's a bit more perspective. When retrieving data, I want to modify the query in the DataSource because it's closest to the data I'll be retrieving. The DataSource is my last chance to change the query before it goes to the database. Similarly, when working with updates -- the data that the user has entered on the page -- I want to work with the DataView because it's closest to the new data. The DataView is my first chance to touch the user's changes.
So, this week, in looking at managing updates I'm going to be looking at events on DataViews.
Maintaining Data Integrity
You have a number of alternatives for checking data before it goes to the database. You can, of course, use the DataValidators which I'm a big fan of (see my column on
CustomValidators). While using Validators is relatively easy, unfortunately, incorporating validators into the GridView or the DetailsView is awkward.
You can also build data checks into your middle-tier business objects. However (more philosophy), I also believe that your business objects are best suited for implementing business rules rather than basic data checks. For instance, to check the data type of an input value (e.g. to ensure that no string values are passed where an integer is required) in a middle-tier business object, method parameters must be declared as String or Object.
The DataView has events that let you write any code you want to check your data before doing any updates.
Using DataView Events
Around every update, DataViews fire two events: one event before the update (with a name that enters with Inserting, Deleting, or Updating) and another event after the update (with a name that ends with Inserted, Deleted, or Updated). In the GridView, the events are prefixed with "Row" (e.g. RowUpdating, RowDeleting); In the FormView and DetailsView, the events are prefixed with "Item".
The *ed events are excellent for checking to see if the updates have succeeded (see my 2008 column titled Handling Update Exceptions in the DataView Events). The *ing events are more important, though: These events are where you ensure that only good data makes it into your database.
In the Updating event, the e parameter has two collections for checking data: OldValues (which returns the values originally displayed to the user) and NewValues (which returns the values going to the database). The ability to access both the original values and current values on the form also lets you check for specific changes. The Inserting and Deleting events, however, have only the Values collection (rather than the OldValues and NewValues collection).
To use the *Values collections, just pass the name of the fields that you want to check. If you find a problem, you'll want to inform the user of the error (probably by putting a message on the page) and prevent the update from proceeding. Stopping the update is easy: just set the e parameter's Cancel property to True. This example rejects a specific change:
If e.OldValues("Region") = "SP" And _
e.NewValues("Region") = "BC" Then
Me.UpdateErrorLabel.Text = _
"Customers can not be moved across continents."
e.Cancel = True
End If
Final Notes
In the GridView, the e parameter also includes the RowIndex property, which allows you to access the row in the Grid where the change was made.
The e parameter also gives you access to the Keys property, which like the *Values collections, returns the current value of a field. The fields available in the Keys collection are controlled by the names in the DataKeyNames property of the DataView. If the DataView is bound to a SqlDataSource, the DataKeyNames property will usually default to the name(s) of the primary key field(s). With an ObjectDataSource, you'll need to specify the fields you want to use in the DataKeyNames property of the DataView.
With the tools in these last three columns, you're ready for the "page from hell" that I described in my
Dynamic Data Retrieval column last month: Dynamically retrieving data based on the user's input and validating data as it's entered on the page.
About the Author
Peter Vogel is a system architect and principal in PH&V Information Services. PH&V provides full-stack consulting from UX design through object modeling to database design. Peter tweets about his VSM columns with the hashtag #vogelarticles. His blog posts on user experience design can be found at http://blog.learningtree.com/tag/ui/.