I love writing code so custom business entity and handed-rolled CRUD classes are a-okay with me. But I'm starting to develop a change in opinion about typed data sets in .NET. It all began last week when I started evaluation ADO.NET 2.0.
First of all, loading data into a DataSet or DataTable is much faster in ADO.NET 2.0, night and day faster. For instance, I ran a speed test that loads 1 million rows into a DataTable. The test took just over 52 minutes to load the 1 million rows using ADO.NET 1.1. The same test took only 27.36 seconds using ADO.NET 2.0. Now that's a performance improvement. If you previously discard DataSet and DataTable because of performance reasons, you owe it to yourself to take another look at them in ADO.NET 2.0.
A typed data set is nothing more than code generated by Visual Studio that inherits from the DataSet and DataTable classes, among others. You can view a typed data set as nothing more than a set of generated business entity and CRUD classes. Because typed data sets inherit from DataSet and DataTable, they share the same performance boost given to its parent classes. But this alone did not convince me that typed data sets finally have a place in the development world.
Visual Studio.NET 2005 really impressed me on how easy it is to now create a typed data set. The wizards make it easy to associate your CRUD stored procedures to the table adapter, and you can just as easily extended the functionality to include adhoc queries and other non-CRUD stored procedures. And Visual Studio will generate over 800 lines of code that handles concurrency checking and other ADO.NET best practices with a simple drag and drop action. As much as I hate to say it, this is faster than writing your own business entity and CRUD classes.
The invention of a type data set is about improving a programmer's productivity and Visual Studio 2005's implementation of typed data sets does just that. It is one of the most productive ways I have seen to build data access and entity classes. I will definitely consider using typed data sets in future .NET 2.0 work. posted by Kirby | 09-Nov-2005 9:39 AM | comments (3)
WOW! That is some HUGE speed difference. And, yes, I basically considered ADO.NET to be nothing short of JUNK when I first tried it. We tried to write a feature-equivalent (to Delphi with MIDAS and dbExpress under Delphi) version of our software product using ADO.Net and C#, only to encounter HUGE performance hit, and HUGE memory-consumption issues with ADO.NET.
Well, it is nice to know MS has changed it for the better. At least it provides hope if I ever need to migrate our product to DotNet.
I agree. Microsoft folks did a superb work with new ADO .NET.
But there's a huga handicap using typed datasets as bussines entities: You can't inherit from another entities, because we don't have multiple inheritance in .NET.
I'm considering about write down my own entities, but keeping a "data entity" generated by VS2005 inside each bussines logic entity.
Have you considered using interfaces with partial classes? This should give you the same effect without actually inheriting from other classes.
posted by Kirby Turner | February 20 06:10 AMAdd Your Comment
