Well, I'm out in San Francisco this week to teach ASP.NET with C# to half a dozen students, and that's going quite well. I had the opportunity to see Alan Shalloway speak at the Bay Area User Group on Tuesday night, and met up with ASPAlliance columnist Steve Sharrock there for the first time as well. We had dinner the next night, and he mentioned something he had used for a solution for a client that I was unaware of.
For a bit of background, it's commonly understood that the standard paging functionality of the ASP.NET DataGrid is quite limited, especially for any significant amount of data. This is due to the fact that the solution relies entirely on having all of the data available to every page in ViewState, which can meen huge amounts of data being sent to and from the web server with every request. There are several solutions to this problem that use custom paging. One that I had thought was the "best" is described in this article by Doug Seven, which uses stored procedures that are smart enough to return only the rows for a particular page. The code required for this is pretty ugly, though, and the work required on the database side is substantially more than for a simple query. Another custom paging article by Curtis Swartzentruber builds on this technique but also doesn't use the technique Steve Sharrock presented to me.
Apparently, there is an overload for the DataAdapter.Fill() method that I had overlooked. This method lets you fill a DataSet (or DataTable) by providing the following parameters:
(DataSet dataSet, int startRecord, int maxRecords, string srcTable)
Using this, Steve explained, it was very simple to create a custom paging solution that used the standard stored procedures (e.g. it didn't require re-writing the sprocs so they understood paging) and which performed as well or better than implementing the paging logic on the database server. It also eliminated the need for passing around tons of ViewState data. All in all, it seems like an elegant solution. I haven't yet had a chance to put it into practice or (obviously) to benchmark it, but I hope to do so in a future ASPAlliance article if Steve doesn't beat me to it.
I'm really getting more and more into unit testing and testing frameworks. At the moment I'm using NUnit 2.0 for my test purposes as I redesign ASPAlliance.com's content management system for integration into the Microsoft Codewise Community standard specification for Federated Search. I'm working with a friend and fellow columnist, Jonathan Cogley, who suggested a this resource on Unit Testing Database Code.
I've developed my own set of DAL code test cases that I've been using for the last few months, but this article offers a fresh perspective on how to set up the testing environment for such components. One recommendation that the author makes is to have as many as 4 separate databases for an application, including a production database and a local developer database, as well as a central development db with realistic amounts of data and a deployment database with a copy of the production database for final testing. For my own development purposes, I think this would probably be overkill. However, I do like his idea of having test cases go against a database that is used solely for testing, and which the tests are responsible for populating with data and cleaning up. I plan to write an article of my own showing the standard NUnit test fixtures I've come up with for my DAL layer as soon as I have a content management system completed so that I can write the content!
That's all for today. Hopefully some day soon I'll be out from under the gun to produce books and/or application code and I'll be able to crank out some of the many articles and book reviews that I now have on hold.
Microsoft has a Team Development Build Tool called BuildIt which you can download here.
From their site:
"BuildIt.NET is designed to jump-start the build process used for development of .NET distributed applications. This download provides full source code and comprehensive documentation for the Microsoft Visual C#® development tool and Microsoft Visual Basic® .NET development system."