Using XML Schemas to Create Strongly Typed DataSets
There is a disjunction between a relational database and objects. A relational database exists to optimize the storage of data and reduce redundancy. Often this means the logically related elements are contained in separate tables. For example, a customer, his address, and phone numbers likely reside in separate tables but are all elated to a Customer. In the database the phone numbers and addresses reside in a separate table to promote only using as much space as necessary, but when that data is presented to the user it is often necessary to reconstruct the data as a whole, for example when printing customer invoices.
We know from experience that one can write a stored procedure that returns the data joined into a single whole. This is not very objected-oriented though because it does not allow for the co-existence of behaviors, for example, a regular expression that validates phone numbers. To resolve this disjunction one can define new objects that include the data from the database and add-on behaviors. The difficulty here is that one loses the simplicity of talking directly to the database, while gaining the power of robust, coherent objects. Using cursors directly in the presentation layer is generally considered client server, and adding a middle-layer that captures the problem domain is called n-tiered. Client-server is fast and convenient, but results in a weak object model. This disjunction is best illustrated by the vendors trying to promote object-oriented databases.
If we stop with a strongly typed dataset then client server code by itself becomes more expressive. However, if we only modify the typed DataSet via generalization (inheritance) then we can re-generate the DataSet anytime the database changes without breaking our code or losing our customizations. In toto the result is very expressive code that easily incorporates business rules that can not easily be captured in a database.
Visually Defining the XML Schema
XML has many uses in .NET. One particular use is to use XML as a means of capturing a database's schema. This technology is referred to by the initials XSD. There is an XSD tool that ships with Visual Studio .NET and the .NET Framework SDK named xsd.exe, and Visual Studio .NET contains an XSD Schema Designer that permits the visual definition of an XML schema. An XML schema and .NET's CodeDOM can be used to convert the XML schema into code; the code is a class that implements a strongly typed implementation of the schema.
As a refresher the weakly typed database operations are exhibited by indexing DataSets and DataTables to return columns or rows, and a strongly typed DataSet yields typed members. The difference in the code is its apparent expressivity. Using weakly typed ADO.NET one might index a table with a row and column name, which may or may not yield a result and that result will be typed generically as an Object. Using a strongly typed DataSet results in code that is expressive in the context of the solution domain. Instead of Tables, indexes, and columns on writes code in terms of entities in the solution domain, for example, customers and phone numbers.
While many good applications have been written using weakly typed client-server code, improvements are gained by employing typed, expressive code that conveys greater meaning, requires fewer explanatory comments, and is more robust due to its concision. (If typed and untyped objects seem foreign to you then a background on the benefits of strong types can be explored in Grady Booch's "Object Oriented Analysis and Design with Applications" from Addison Wesley.)