Yesterday I gave my two presentations here at TechEd Europe: one to overview the new features of ADO.NET 2.0 and one to show what can become of your (badly written) Web app if only a hacker hangs out around it.
Overall, I've got good scores above the average and want to thank all of the attendees who listen here. Particularly those from the Czech Rep needing some special type of comfort after the yesterday's game. Congrats instead go to TechEd attendees from Portugal and Greece. Football-wise these two countries represent a pleasant blast of fresh air. May the best win Sunday!
Back to ADO.NET 2.0, I've seen that some attendees (close to 1,000--unbeliavable) complained about the rhythm of the presentation that they judged way too slow. In particular, some of them pointed out that I spent too much time speaking of just ONE feature--the new DataSet's capability of native binary serialization.
My (strictly) personal opinion is that DataSet's binary serialization is THE feature, as long as ADO.NET 2.0 is concerned. All in all, ADO.NET 2.0 doesn't have a huge amount of changes to showcase. Sizeable batch update, factory model for providers, even the integration with SQL Server 2005 pale out (again, strictly personal opinion) compared to importance of binary serialization of DataSets. Why?
Because binary serialization of DataSets impacts thousands of existing enterprise multi-tier apps that use .NET Remoting to move data across the tiers in a disconnected manner. Let me write it out more clearly.
If you follow the best and most recommended MS practices for building effective .NET-based distributed apps, you use the DataSet to move data across tiers and Remoting to get the best of performance. If you do so, though, you bump into the limitation (to say the least... are perhaps bug or design flaw better terms?) of 1.x DataSets. They always serialize to XML diffgrams thus raising the amount of required memory, CPU, bandwidth by 10 or more times.
A blonde, nice and gentle attendee from Germany confessed she had a hard time last year figuring out what was wrong in her app and resorted to network sniffers to pinpoint the problem--DataSet serialization. As Rod Stewart was used to sing, blondes have (always?) more fun...
The chart above illustrates the end-to-end speed of a remoted DataSet as the number of involved rows grows. The yellow series (almost flat) is the performance of DataSets optimized as in version 2.0. The pink series shows the performance of DataSets in version 1.x. When the number of rows exceeds a certain threshold (1,000 records) the difference gets remarkable to become intolerable beyond 10,000 rows. (Just the size of real-world projects...)
Compared to this, even the SqlDependency class that gets you notifications of database changes that affect the results of a query command you run previously, is a sort of child's toy.
Comments?
PS: Credits go to Corrado Cavalli for the pictures.