So, this question may be a little vague, but I have constant discussions about it:
When designing an Asp.Net page, a lot of times you might just want to throw a quick and dirty GridView on the page. When you are going that route you have the various datasource options (I typically use ObjectDataSource tied to a business object) and you can also manually bind.
I have seen a lot of variation on what datatypes can automatically provide the sorting functionality within the grid. I have seen people literally translate their custom POCO collections into DataTables in their business objects so that GridViews can more easily support these types of behavior.
You can really get a lot of different behaviors out of a GridView by handling all of the available events yourself (OnSorting, OnUpdating, etc.) and it can end up highly customized in the long run. Even though this is the case, you can run into sneaky other little problems like not having the ability to use the “Enter” key automatically perform the update operation for a given row. This is because the default button on the page might be outside the GridView, and ASP.Net only lets you specify the default button for a given panel and does not honor this behavior for buttons inside GridView templates. That is just an example, mind you. There also is of course the question about whether or not the page should go back to the data source upon each filter operation or whether or not the entire datasource should be cached in ViewState on the page to allow filter/sorting without a trip to the DB…
So here is the ultimate question: Is it reasonable to use a GridView on a page where you want basic CRUD operations even if it might mean transforming your custom collections into some kind of DataTable? Should GridViews be abandoned completely in favor of something else like a DataList, ListView, or Repeater? The latter options certainly might be more flexible, but does that mean handling the default row selection, editing, sorting, etc. functionality of the GridView should be rebuilt for each scenario?
Any reasonable thoughts on this subject appreciated!
I just realized this question was still hanging out here so here is my conclusion on this topic:
I still think it is useful to embed a standard GridView control within an ASP.Net page. I still think it is unreasonable to handle every sorting event in the code-behind for a page as it makes for a real maintenance nightmare and slams your data-interaction and business-logic code too close to the “View” in MVC terms…
What I was unaware of was how tightly integrated GridViews can be with the various DataSource controls. I knew that given the right circumstances a GridView when connected to a SqlDataSource would execute various CRUD operations directly against the database while applying its own Sorting and Paging techniques, but that didn’t translate well to using an ObjectDataSource with a business object -or so I thought.
Turns out there are three crucial properties on the ObjectDataSource control which allows it to dynamically supply a method on a business object with sorting and paging parameters.
These properties are : SelectCountMethod, SortParameterName, StartRowIndexParameterName and MaximumRowsParameterName. These properties in conjunction with the required EnablePaging flag change the expected signature of your “Select” method and starts automatically using your SelectCount method to get the total possible numbers of records returned, using your GridView’s page size and current state to determine where to begin in your result set and how many items to select beyond that start point, and starts submitting a SQL-style sort expression along with all calls to your Select method.
All in all, this was a big step forward, but if you are using custom collections of POCO classes, or executing queries against a LinqToSql or EF object context, you still have to translate the StartRowIndex and MaximumRow parameteres into some form of a Skip().Take() combination (which is pretty straightforward and obvious) and translate the Sort expression into some type of query against your object context or in-memory collection.
I won’t get into all the lengthy specifics here, but basically the solution is to use the dynamic-Linq capabilities and reflection to define a query expression against your in-memory collection with only the Sorting string to go on.
The Sorting string will contain a field name and a sort direction (only if descending) in the typical “FieldName DESC” format. By parsing this string you can use reflection on your specific type to create an expression using the matching property name from the Sort string.
The main benefit here is that with only a few tweaks to the select method and the use a custom Linq extension to handle the conversion of a sort string into a lambda expression you can go about your regular business of wiring up GridViews to business logic with build in sorting, and paging functionality.
Because it was mentioned in the original question, I will note that this solution will result in a hit to the database on virtually every page load, but ultimately the amount of data returned should be much smaller and more targeted.