Programming Microsoft ASP.NET 4 - Dino Esposito [244]
Important
ObjectDataSource allows data to be retrieved and updated while keeping data access and business logic separate from the user interface. The use of the ObjectDataSource class doesn’t automatically transform your system into a well-designed, effective n-tiered system. Data source controls are mostly a counterpart to data-bound controls so that the latter can work more intelligently.
To take full advantage of ObjectDataSource, you need to have your DAL already in place. It doesn’t work the other way around. ObjectDataSource doesn’t necessarily have to be bound to the root of the DAL, which could be on a remote location and perhaps behind a firewall. In this case, you write a local intermediate object and connect it to ObjectDataSource on one end and to the DAL on the other end. The intermediate object acts as an application-specific proxy and works according to the application’s specific rules. ObjectDataSource doesn’t break n-tiered systems, nor does it transform existing systems into truly n-tier systems. It greatly benefits, instead, from existing business and data layers.
Caching Data and Object Instances
The ObjectDataSource component supports caching only when the specified select method returns a DataSet or DataTable object. If the wrapped object returns a custom collection (as in the example we’re considering), an exception is thrown. Custom object caching is something you must do on your own.
ObjectDataSource is designed to work with classes in the business layer of the application. An instance of the business class is created for each operation performed and is destroyed shortly after the operation is completed. This model is the natural offspring of the stateless programming model that ASP.NET promotes. In the case of business objects that are particularly expensive to initialize, you can resort to static classes or static methods in instance classes. (If you do so, bear in mind what I said earlier regarding unit testing classes with static methods.)
Instances of the business object are not automatically cached or pooled. Both options, though, can be manually implemented by properly handling the ObjectCreating and ObjectDisposing events on an ObjectDataSource control. The ObjectCreating event fires when the data source control needs to get an instance of the business class. You can write the handler to retrieve an existing instance of the class and return that to the data source control:
// Handle the ObjectCreating event on the data source control
public void BusinessObjectBeingCreated(object sender,
ObjectDataSourceEventArgs e)
{
BusinessObject bo = RetrieveBusinessObjectFromPool();
if (bo == null)
bo = new BusinessObject();
e.ObjectInstance = bo;
}
Likewise, in ObjectDisposing you store the instance again and cancel the disposing operation being executed:
// Handle the ObjectDisposing event on the data source control
public void BusinessObjectBeingDisposed(object sender,
ObjectDataSourceDisposingEventArgs e)
{
ReturnBusinessObjectToPool(e.ObjectInstance);
e.Cancel = true;
}
The ObjectDisposing event allows you to perform cleanup actions in your business object before the ObjectDataSource calls the business object’s Dispose method. If you’re caching the business object, as the preceding code has done, be sure to set the cancel flag so that the business object’s Dispose method isn’t invoked and the cached object isn’t as a result stored in a disposed state.
Setting Up for Paging
Three properties participate in paging: EnablePaging, StartRowIndexParameterName, and MaximumRowsParameterName. As the name clearly suggests, EnablePaging toggles support for paging on and off. The default value is false, meaning that paging is not turned on automatically.