Introducing Code Generation - The Strongly Typed Dataset

(Page 10 of 13 )

The ADO.NET strongly typed DataSet is a piece of application-level code generation within the .NET Framework. It’s hard know what to say about a construct that moved us so far forward in how we think about data containers and yet presents such a flawed implementation. Visual Studio generates strongly typed DataSets through an external tool named XSD.EXE. Code in this tool accesses your XSD for metadata and uses the CodeDOM to explicitly produce output. There’s no available template, and you can’t alter the output.

Strongly typed DataSets are a hybrid between the significant power of DataSets and the strong typing benefits generally associated with business objects. Solutions built with the strongly typed DataSet are easily bound8 and support cascading inserts of primary keys by default. It’s “normal” code that you can learn from, rather than some hidden black box. Generation based on the XSD standard gives the strongly typed DataSet broad applicability. That’s the good news.

Unfortunately, most projects will run into problems because of one or more of the following problems with the implementation in Visual Studio 2002 and 2003:

• DataTables are inextricably linked to specific DataSets, massively reducing the possibility for reuse.

• Although not sealed, you can’t effectively derive from the strongly typed DataTable or strongly typed DataRow because you can’t override their instantiation within the DataSet.

• You can’t specify the base class.

• Column metadata is Friend (assembly), so code in a different project can’t access it via strong typing.

• Strongly typed DataSets don’t incorporate all available metadata from the database or XSD. For example, they don’t provide privileges, constraints, or extended properties.

• It’s awkward to provide variations in null handling.

• Mapping of columns is difficult and easily lost on regeneration.

• Validation can’t be included in the strongly typed DataRow or DataTable.

• Users of your class can circumvent using the strongly typed DataSet, even avoiding strong typing.

If you could modify the way a strongly typed DataSet is generated when you ran into one of these problems, it might be appropriate for your application development. If you want to use the strongly typed DataSet, I include an XSLT template for code generation in both VB .NET and C# in the Downloads section of the Apress Web site (http://www.apress.com). It’s not complete and doesn’t cover as many details (such as annotations) as the Microsoft-supplied strongly typed DataSet. But for mainstream use, it gives you a fallback position if you run into a problem with the strongly typed DataSet because you can make changes to it. Without a backup plan, I think the strongly typed DataSet is a time bomb in most environments because when you run into a brick wall, it’s a very solid brick wall that can derail your development.

*********************

8. You can bind strongly typed properties at design time. You can’t bind an untyped object such as a standard ADO.NET DataSet or DataTable through property dialog boxes at design time.

You can’t solve the problem of programmers being able to circumvent the strong typing in any design that derives directly or indirectly from the DataTable class. That arises because you can’t fully hide access to base class members. In your own designs, you can circumvent this issue by wrapping the DataTable, rather than inheriting from it. In designs that do include DataTable derivations, use events such as the ColumnChanging event to respond to key actions such as changing the value, rather than properties the user could circumvent.

The strongly typed DataSet is useful from a pedagogic, or learning, perspective. The basic approach of code generation is to apply a structure or pattern to the details of your application. One way to get an idea of what structure and patterns mean in your application is to look inside a strongly typed DataSet. To do this, create a strongly typed DataSet and locate its source code:

1. Add a new DataSet to your project through the Project menu of Visual Studio.

2. Drag a couple of tables onto the design surface and set relations between them.

3. Select Generate Dataset from the right-click menu.

4. Click the Show All Files button at the top of Solution Explorer.

5. Expand the XSD entry in your project, and you should find the source code as a .vb or .cs file.

Open the strongly typed DataSet source code, and scroll down to one of the tablenameDataRow classes (a few hundred lines). You’ll see a typed property for each column in your DataTable. The code varies depending on whether the column is nullable or not nullable. The code generator has applied a pattern to the metadata retrieved about each column in the DataTable. The pattern varies based on the specific input, such as nullability. If you scroll around this file, you’ll see many other examples of patterns as well as some pretty big blocks of code that are more or less the same for all instances of the strongly typed DataSet. Your own template patterns will also contain chunks of code that are relatively static and chunks that change for each table, column, or other entity.

The strongly typed DataSet inspired parts of the code generation journey I’ve been on. It convinced me that .NET offered features that let code generation finally work for my applications. Bashing my head bloody on the strongly typed DataSet left me no doubt that you and I could do a better job and reinforced that we required control over critical pieces of my application, and things just grew from there.  

This chapter is from Code Generation in Microsoft .NET by Kathleen Dollard (Apress, 2004, ISBN: 1590591372). Check it out at your favorite bookstore today. Buy this book now.

Next: Performing Real-World Code Generation >>
 

More .NET Articles
More By Apress Publishing

Comments On: Introducing Code Generation

>>> Be the FIRST to comment on this article!