RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


Smarten Up Your DataSets with XML Schema

Go beyond Visual Studio’s graphical tools to bring increased power and flexibility to your data layer. Learn how to modify your XML Schema and live in peace with your DBA.

ou might as well face it; your data model is going to change. You can whine about it. You can fight with the DBA and the requirements team. Or you can get ready for the change before it happens. This article focuses on the last option, giving you some techniques to build a more flexible data layer.

By now, you're probably sold on the benefits of the typed DataSet. The accessor methods make client code friendlier to write and easier to debug. Best of all, Visual Studio creates the typed classes for you automatically. But the typed DataSet can lack flexibility. Datasets are often described as an "in-memory database"—and that may be a good description, because they seem to have all the shortcomings of a relational database. These shortcomings can include lack of code-reuse and difficulty interfacing with object-oriented systems.

Worst of all, DataSet lacks inheritance, so you often end up with the same fields or even the same tables defined more than once. As your DataSets grow more complex, two potential problems emerge:

  • All the tables are defined independently, no matter how many fields they might have in common. It's a little like the bad-old-days before true object-oriented programming.
  • There's no obvious method for sharing a table definition across multiple DataSets.
Overcoming these limitations is relatively easy—if you know a little XML Schema Definition language (XSD, also known as XML Schema.). In case you're new to XML Schema, this article includes a quick introduction. Next, you'll see how to tweak the XSD documents created by Visual Studio to create custom, reusable XSD types. Finally, even XML can't solve all the world's problems (no matter what their marketing departments say), so it's worth taking a look ahead to the next release of Visual Studio to see what it has to offer for data-layer developers.

XSD for Short Attention Spans
XSD is an XML-based language used to define a set of rules that apply to other XML documents. ADO.NET uses a lot of XML under the hood, so it makes sense that Visual Studio uses XML Schema to define the typed DataSets that it generates.

The easiest way to discover a little more about XSDs is to explore. To begin, drag a table or a view from the Server Explorer into the graphical designer. Figure 1 shows a screenshot of the sample project's visually-designed DataSet.

Figure 1. Auto-Generated DataSet-Designer View: The figure shows a ordinary dataset, created by dragging tables from the Server Explorer nto Visual Studio's visual designer.
Even if you've never examined the code, you've probably seen the XML tab at the bottom of the DataSet designer. Click on the XML tab and take a look at what's going on behind the scenes. You should see something similar to the code in Listing 1.

The W3C created the XSD specification as a language capable of defining a wide variety of XML documents, not just datasets, so not every tag is useful or interesting to you as a DataSet consumer. Some tags you'll use only as placeholders; others you won't use at all. Table 1 shows some of the most common XML Schema tags you'll work with for modifying DataSets. For a more detailed explanation of XSD, check out this tutorial.

Table 1. XML Schema Basics




Defines the "leaf level" of an XML document. Used mostly for creating columns in ADO.NET schemas.


The root tag, which contains just about everything else in the document.


Used to define anything more complex than a single column, such as DataSets and DataTables.


Defines an ordered collection of elements, such as a series of columns. For ADO.NET developers, this element functions primarily as a placeholder.


Adds an external schema to the current document. Similar to the using keyword in C#.

Here's the XSD schema for a simple table definition:

   <xs:element name="ClassRoom">
         <xs:element name="ID" type="xs:string" />
         <xs:element name="Floor" 
            type="xs:unsignedByte" />
         <xs:element name="RoomNumber" 
            type="xs:string" />
         <xs:element name="timestamp" 
            type="xs:base64Binary" />

Customizing the XSD is easier than you might think. In fact, it's a lot like programming in .NET. You start by defining types and giving them attributes. And, just like .NET, XSD allows you to extend types. Digging a little deeper into XSD gives you the power of code-reuse without giving up the ease of automatically-generated DataSets.

Close Icon
Thanks for your registration, follow us on our social networks to keep up-to-date