Thursday, June 30, 2005

Typed datasets in ADO.NET

In ADO.NET when I came across the concept of typed data-set (using the XSD.exe tool), the first question I had on my mind was "WHY?" What are the advantages?

.NET SDK help states the following:
A typed DataSet is a class that derives from a DataSet. As such, it inherits all the methods, events, and properties of a DataSet. Additionally, a typed DataSet provides strongly typed methods, events, and properties. This means you can access tables and columns by name, instead of using collection-based methods. Aside from the improved readability of the code, a typed DataSet also allows the Visual Studio .NET code editor to automatically complete lines as you type.

Additionally, the strongly typed DataSet provides access to values as the correct type at compile time. With a strongly typed DataSet, type mismatch errors are caught when the code is compiled rather than at run time.
So I understand that one of the advantages of using typed datasets is that you will catch typos in table and column names at compile time not run time as with un-typed data sets. In fact using intellisense eliminates those typos all together..

But during the earliers states of the project. when the database may keep changing according to requirements, U would need to synch the database with the code everytime !!!...Anyway, my personal belief is that all errors relating to column names etc. should be captured during unit-testing. (Or is this impossible in a mega-project and the overhead of manually creating dataset schemas would be justified?)