Weekly commentary: Weighing in on Typed Datasets

I’ve had some recent discussion with developers about typed datasets. I use them regularly. Here are the benefits I’ve enjoyed from them (no order of importance):

• Typed datasets give you the ability to use IntelliSense for statement completion, and type checking at compile time.   They also make it easy to define default column values when you add new datarows.
  
  You can also read a column value directly without needing to write a conversion (int Qty = MyDataRow.MyQty, instead of int Qty = Convert.ToInt32( myDataRow["MyQty"]). 

• If a typed dataset contains table relations, the XML schema definition tool adds methods to the typed dataset class for traversing hierarchical data.  For example, a developer can write parent/child code for the tables DtOrderHeader and DtOrderDetail by using two methods that the .NET schema tool automatically generates: GetDtOrderDetailRows and GetDtOrderHeaderRow.  (A developer can use annotations to define alternate naming conventions: I'll cover this at the end).

• Additionally, if you define a primary key for any table in a typed dataset, the class exposes a Find method associated with the column name.   A developer can perform a FIND against a table with a primary key of OrderID by using the method FindByOrderID.  If the primary key is a concatenation of two columns (CustomerID and OrderID), the developer would use FindByCustomerIDOrderID. 
  
  In general, there’s less code to write because the typed dataset class contains generated code for building the schema and creating the necessary table, column, row, and relation objects.  The code you do have to write can be cleaner, more compact, and easier to maintain.

• Working with null values is a little easier when using Typed Datasets.  Each strongly-typed datarow contains a method to check if a column value is null…if MyRow.IsAddressNull().  The datarow also contains a second method to set a column value to null….MyRow.SetAddressNull().    Again, I'll cover annotations below, which also provide flexibility in dealing with nulls.

• Typed datasets serve as documentation for stored procedure result sets.  This benefit becomes even more important on multi-developer projects.   You can also define typed datasets as a separate project/DLL and then set references to them from the projects that use them.

• Typed datasets are valuable in the reporting process.   A developer can design report content from a typed dataset definition, even before the stored procedures are constructed.  Once again, the typed DS becomes a form of documentation for the report datasource.  I’ve developed hundreds of reports using different data access methodologies, and find typed datasets to be the most efficient.

• You can subclass a typed dataset class to add validation code or any other methods for the dataset.

• Typed datasets can simply design-time data binding – a developer can define a data source in the property sheet.    Developers who define data sources in code still gain the advantage of table/column name discovery through Intellisense.
  
  Typed datasets aren’t perfect.  They carry overhead.  While certain specific aspects of typed datasets are faster than untyped datasets, instantiating a complex typed dataset can be costly.  An application that frequently creates an instance of the same typed dataset will spent a measure percentage of time on the creation process.  Uri N. has developed a proxy class for typed datasets so that the actual creation only needs to occur once.   You can find his class on the CodeProject.
  
  Another complaint about typed datasets is the default naming conventions in the Typed dataset class for items like the DataTable/DataRow objects and methods/events.   The generated names may not be consistent with the preferred naming conventions on your development projects. Fortunately, developers can use Typed Dataset Annotations to solve some of the common naming issues, by allowing developers to modify the names of elements in the typed Dataset without modifying the actual schema. 
  
  Annotations also allow you to specify a nullValue annotation to instruct the typed dataset class how to react when a column is DbNull.  You can optionally tell the typed dataset to return an empty string or a default replacement value.  Shawn Wildermuth demonstrates typed dataset annotations in this excellent online article.  
  
  Another common criticism of typed datasets is that developers must update them anytime a stored procedure changes.  That is true.   (And in reality, if you add a column or table to a result set, the new data will appear in the dataset: it just won’t be strongly typed).  However, if new columns or tables are added to a stored procedure, chances are good that other components of the application will be modified as well to reflect the new data (screens, reports, validations, etc.)
  
  I work heavily with stored procedures, complex result sets, data views, and business/financial reporting, so typed datasets are an important ingredient for me in development methodology and producing results.
  
  I give credit to Bonnie Berent for helping me understand the value of typed datasets.  I used them immediately when I started working with Crystal Reports .NET, but she's helped me over the years to understand and take advantage of the other benefits they provide.  Bonnie answers many .NET questions on on-line forums like The Universal Thread, GotDotNet, as well as other Microsoft Newsgroup forums.
  
  Coming this week:  some Crystal tidbits, and a discussion of functionality in the Common Ground Framework.  Stay tuned!
  
  Jazz recommendation for the day: Personal Appearances by Sonny Stitt.  A must-have for bop lovers.
  
  Peace out...KG

Comments

[Bonnie Berent]

Hey Kev, thanks for mentioning my name. Keep up the good work. =)