This post originated from an RSS feed registered with .NET Buzz by Brendan Tompkins. Original Post: An ObjectDataSource/GridView Adapter for Business Entity Collections Feed Title: Brendan Tompkins Feed URL: /error.htm?aspxerrorpath=/blogs/brendan.tompkins/Rss.aspx Feed Description: Blog First. Ask Questions Later. Latest .NET Buzz Posts Latest .NET Buzz Posts by Brendan Tompkins Latest Posts From Brendan Tompkins

Using ASP.NET 2.0’s new GridView control with the new ObjectDataSource allows you to properly layer your applications.  You can create strongly-typed collections of your business objects, and quickly bind them to the new Grid.  The hype sounds good.  Real good, in fact:

From Move Over DataGrid, There's a New Grid in Town!

The GridView control is the successor to the DataGrid and extends it in a number of ways. First, it fully supports data source components and can automatically handle data operations, such as paging, sorting, and editing, provided its bound data source object supports these capabilities.

The key phrase here is “provided its bound data source object supports these capabilities” When you bind your GridView to an ObjectDataSource wired to a DataSet, DataView or DataTable, you do indeed get automatic sorting, and paging, and you can also filter your data through the ObjectDataSource’s FilterExpression property.  All this adds up to a really useful control, one that you can base your entire web applications around. 

Business Entities and SOA.

Okay, great. Well, say you’ve been using Business Entities and Strongly-Typed collections in lieu of DataSets to build your application framework and business layers.  If you’ve been developing this way, you’re probably a convert.  Having a nice, clean framework of entities can be a great foundation for application development.  You also may be using a service oriented pattern to return these entity objects, instead of filling your objects with an instance method of the business entity itself. 

Both of these patterns are good to follow, but neither work out very well using the ObjectDataSource.  If you’ve done this and you try wiring up these collections to an ObjectDataSource and GridView, you’ll find that a Strongly-Typed Collection doesn’t work with the filtering (setting the ObjectDataSource’s FilterExpression property) and automatic sorting capabilities of the GridView.  The GridView’s current implementation requires that you use a DataTable, DataSet or DataView, unless you want to handle these events yourself and do your sorting on your own.  It will automatically do paging, but other than that you’re on your own.

It also doesn’t like the service oriented/entity pattern much.  It actually works best when you have smart business objects that are DataTables, DataSets or DataViews and also implement methods which populate the entities.  In Fact, the ObjectDataSource’s control designer won’t complete until you specify which method on your business object is the “Fill” method. This is too bad, because often what we need is to be able to use our entity objects, our service tier methods, and a nice GridView that does the sorting/paging/filtering stuff easily. 

Since this doesn’t exist currently, the next best thing is to create a DataTable, fill it with your entity collection’s data, and hand this off to the GridView for presentation.  It’s a little strange having to go back to a DataTable after having built a nice clean framework of entities.  Whenever I find myself having to revert back to using DataSets or DataTables, just for the sake of using one control or another, I feel Michael Corleone in Godfather III -  “Just when I thought that I was out they pull me back in.” 

This is where I really can jibe with Jeffrey’s RAD Kills message.  We have this great RAD grid, but to use it you have to revert to a sometimes poor design choice (DataSets). 

The EntityDataTable – Best of Both Worlds?

To solve this problem of allowing my business entity collections to be quickly bind-able to a GridView I whipped together a quick abstract adapter class which I can sub-class that is actually a DataTable. This way, when I bind it to a GridView, it will support all this auto-sorting/filtering stuff.   This class has two methods, GetDataTable which uses reflection and returns a DataTable containing a column for each public property in my entity class.  It also contains an abstract method Fill which can be overridden to connect to your service tier, get your collection, and call the GetDataTable method with your collection and your collection’s contained type.

EntityDataTable in Action

Here’s a quick example of a derived class, that adpts my SomethingCollection to easily work with the GridView and ObjectDataSource.

And here’s a quick ASCX control snippet that shows it all tied together:

All that's left for me to do is pop my parameter in the session, and call GridView1.DataBind().. Voila!  My grid is bound to my entity collection, sorting and paging work like a charm, and I can filter my data buy calling by setting the Filter parameter of the ObjectDataSource.

[tags: ASP.NET, .NET, C#]