Implementing Business Logic - ASP.NET Dynamic Data - page 273

This type of logic is an example of business rules that define interaction between different
properties of a single entity. This particular rule could have been defined as “Set
SubmittedDate to date and time when the OrderStatus changes from Draft to Submitted.”
OnPropertyChanging Partial Methods
The Entity Framework generates a partial OnPropertyChanging method for each property,
such as the OnOrderStatusChanging method for the OrderStatus property shown here:
partial void OnOrderStatusChanging(byte? value);
When implemented by a developer, this method receives the new value of the entity
property as the parameter and can access the original value through the entity property
itself. At first, it looks like an ideal place to implement the code to set the SubmittedDate
when the new value of OrderStatus property is Submitted . Unfortunately, this approach
does not work in web pages that rely on the EntityDataSource control, such as the page
templates in our Dynamic Data web application.
The data source control does not keep the entity object alive between page requests, nor
does it serialize the object to the server- or client-side state storage. Instead, it puts the
original values of its properties in a hash table and stores the hash table in the ViewState
when the page is first rendered. During the post-back, when the data source control needs
to save changes, instead of reloading the original entity from the database, it simply
creates a brand-new entity object, applies the original values from the ViewState , and calls
the AcceptChanges method of its ObjectStateEntry . Then it makes a second pass to apply
the current values of the entity properties received from data entry controls on the page. In
other words, every OnPropertyChanging partial method is called when any property of the
entity changes.
To put this in a specific example, imagine changing the shipping address on an already
submitted order. Even though the OrderStatus property itself does not change, the
OnOrderStatusChanging method will still be called as if the OrderStatus changed from null
to Submitted . Therefore, if we try to set the SubmittedDate in the OnOrderStatusChanging
method, it would always store the date of the last change made to the order.
ISavableObject Interface
Instead of implementing the partial OnPropertyChanging methods, rely on the
ObjectStateEntry class and explicitly compare the original property values it stores with
the current values of the entity properties. This approach is similar to the approach
discussed in Chapter 8 to implement validation rules based on property value changes. In
fact, you could have implemented this logic in a custom validation method, but mixing
the interaction logic, which changes property values, with the validation logic, which veri-
fies them, is not a good idea. You have no control over the order in which the validation
methods are called and might end up with validation code for a particular property
executing before the code that changes it, leaving the entity in an invalid state.