ASP.NET 2.0 is cool but oh yes, its buggy.
Just like other .NET application developers, I was very much excited about the ASP.NET 2.0 release. I scored a Visual Studio 2005 DVD from release launch event, organized in NYC. From the day one I started working on developing my application in ASP.NET 2.0.
During this course of days, I am very much pissed with the way it works. So far Microsoft Visual Studio Team boasted about more than 50 new controls. The very first I worked on is SqlDataSource & GridView.
These controls are very much useful for Rapid application development. DataGrid from ASP.NET v1.1 requires us to code for Sorting, Paging, Caching etc. But with GridView you don’t need to do that. Cool. It also has EnableSortingAndPagingCallBacks, ofcourse they never worked for me, enabling to refresh just Grid rather than the entire page.
The SqlDataSource controls ability to fetch data based on Parameters from Controls, QueryString, Session, with default values is very nice feature. Even Caching is very much easy. Set CacheDuration, EnableCaching and you are done.
Everything looked awesome until I started writing my own test application. In my test application, I have simple GridView with Sorting and Paging enabled and a SqlDataSource’s Select Command is bound Sql Query from my SQL Server 2005 database. It has EnableCaching set with CacheDuration set to Infinite. The paging and sorting works like charm. I also thought like, in due course of time, developers may forget how we sorted data in ASP.NET v1.1.
To validate its Caching functionality, I started Query Profiler and did some sorting and paging. To my surprise, I found more than 10 logs showing my Query is being run by DB Engine. Well, I cleared up the log and tested again. The log showed that it in deed got requests to execute the query couple of times, despite the fact that Caching is enabled.
Hmm, to validate my profilers functionality, I wrote the code for sorting and paging in our Old school fashion (cache DataSet, use DataView to sort, code events PageIndexChanging & Sorting). This time, Profiler log showed only one request for executing my query. Perfect. So whatz the use of having EnableCaching property for SqlDataSource, which barely functions?
And most importantly, even if Cache is fixed to function, most of the time we developers do store data specific Session. For example, if you write Calendar application. We store user’s ‘To-do tasks’ in Session, because my tasks will be differnt from yours. We cannot do that here, because its a shared space. Atleast, Providing Set access to SqlDataSource’s Cache KeyName, when prefixed with SessionID would do the trick.
Finally, I kept myself composed that I would NOT be using SqlDataSource control because,
- It’s 2-tier architecture developement, which I never use.
- Caching functionality is not working perfectly.
- Not scalable to Cache / Store Session data.
– Shyam K. Arjarapu