Is Strongly Typed Data Important?

Some would have you believe that the only way to build a data structure is to use one of the strongly typed class code generators exposed in Visual Studio. Ah, developers all over the planet have been creating mainstream, high-performance, and highly scalable applications without strongly typed data structures for decades. So what makes a strongly typed DataSet special? Well, instead of declaring an object as a System.Data.DataTable and populating the Columns collection with hand-coded or ADO.NET-generated schema, you either tediously hardcode the thousands of lines of code to build individual columns as properties using specific system types in your own custom "AuthorsDataTable" or you get one of the Visual Studio tools to do it for you. That's what this chapter is abouthow to get Visual Studio to create the new strongly typed TableAdapter class for you.

Behind the scenes, a strongly typed data structure has a matching schema file (.XSD) that defines the structurewhat it should contain and how it should be stored. It can also define relationships between the classes as well as other constraints, custom properties, and methods. This XSD file is used to generate the code used to access the targeted database element.

An untyped DataTable (or any object) has no such defined schema (outside of the database), so it's built with generic system "object" types that can hold anythingit's simply a transport vehicle. When you execute a query that returns a rowset, the ADO.NET DataAdapter Fill or DataTable Load methods construct a DataTable whose Columns collection matches the schema of the incoming rowset. ADO.NET can identify a primary key but not intertable relationships. While the DataType property is set to match the type of the rowset column, it's implemented as an objectnot as a strongly typed property.

Think of a strongly typed DataTable as an egg carton and an untyped DataTable as a basket designed to carry anything you happen to collect. Does this mean the strongly typed DataTable can store egg-size chunks of stuff you might find in a barnyard? Sure. A city slicker won't know they aren't eggs until he tries to crack one open in the kitchen. However, if you want to ensure you only put real (chicken?) eggs in your strongly typed egg carton, you'll have to add custom code to test each item as it arrives. Each block of custom criteria-testing code you add further restricts what the carton can contain. It also means that if you buy a duck, you won't necessarily be able to use your strongly typed cartons without going back and modifying every single application that uses the strongly typed class to accept the new type of egg. Thanks to partial classes, Visual Studio 2005 does not overlay the customizations you make when you rerun the wizards used to create strongly typed data classes, so it can make this process a bit easierbut just a bit.

So what benefit does a strongly typed DataTable (or DataSet) return for your investment in time and the compile-time required for hundreds, possibly tens of thousands, of lines of brittle code? Yes, if a data structure (like a DataTable) is defined explicitly, it cannot accept values that are out of type. That is, if you define a strongly typed DataTable (as the Data Source Configuration wizard does), the columns marked as Int16 won't accept a string or an Int32, but does that make your data pure? Not hardly. A strongly typed Int16 field that's supposed to hold the customer discount (which can be 0, 10, 20, or 30%) is not prevented from holding any Int16 value unless you further edit the generated code to impose this business rule. As you can see, this can be very expensive to implement and even more expensive to maintain.

As I see it, the problem is and always has been that when the underlying data schema or business rules change (as they invariably do), the strongly typed class you or Visual Studio create no longer match the data structure as defined in the database. In our opinion, this is the more serious and insidious problem. From the dawn of time, data structure inconsistency (what I used to call "data exceptions") has caused any number of crippling problems that hard-coded data structures do not address.

One of the most important vulnerabilities of the Data Source paradigm is that the generated code is directly dependent on the database schema (structure) used to generate the code. If the schema changes at design time, Visual Studio usually gets confused and displays what I call the "white window of death." You're lucky, thoughthere's a work-around for this problem. Close the Form's design window, right-click on the Form file in the Solution Explorer, and click Refresh. The Form window should rebuild itself.

If the schema changes post-deployment, you're pooched. Applications that use the DSCW-generated code are hard-coded to match database table and view definitions, store procedure and function signatures, and user credentials. If any of these change, even in subtle ways, your code will likely crash. At this point, your only alternative is to rebuild, recompile, retest and redeploy, and possibly look for another customer.