Why the DataTable not?

Published 07 April 04 08:14 PM | despos

This is a recent question I've found in my inbox.

Both the DataSet and the DataTable implement ISerializable. Why can't a DataTable be returned from a Web
Service? I've come across some pretty vague explanations through Google and MSDN but I'm determined to understand the true technical reason why.

The reason relates to the class that ultimately handles the XML (de)serialization of any .NET type used with a Web service method. This class is XmlSerializer and serializes .NET types to XML. It is fairly different from a .NET formatter and designed to serve different purposes. XmlSerializer is NOT designed to persist the state of an object (like formatters do), but simply to move a snapshot of the constituent data of the object. For this reason, it only moves public members and doesn't even attempt to handle circular references.


XmlSerializer is a class specific of the .NET Web service implementation and could have been kept private as well. You should not use it as an XML formatter. (Looks like a similar class will make its debut with Whidbey.) Because it is not a formatter, XmlSerializer doesn't know anything about the ISerializable interface. In fact, XmlSerializer and formatters push two (radically) different models of serialization with different purposes and features.

So what's XmlSerializer all about? It just transforms any .NET type used as an I/O parameter of a Web service method into an XSD type and vice versa.

In terms of practical features, XmlSerializer doesn't handle circular references and skips over protected and private members. This is its default behavior. According to this, neither the DataSet nor the DataTable are good at
serializing through the XmlSerializer. So why is it supporting only the DataSet? It's a sort of exception.

The XmlSerializer works with simple classes (no circular refs) and with classes that implement IXmlSerializable
(an interface not fully documented in v1.x). The DataSet does implement it; the DataTable does not.

For details, look for the types.cs file in the SSCLI v2 (sscli\fx\src\xml\system\newxml\serialization path) to have an idea of what types are really supported. There are a few more "exceptions" than just the DataSet.

Comments

# Cleve Littlefield said on April 7, 2004 04:45 PM:

I hear tell that in ADO.NET 2.0 the DataTable is now a first class citizen and supports serialization along with other DataSet features.

# TrackBack said on April 7, 2004 06:18 PM:

Take Outs for 7 April 2004

# TrackBack said on April 8, 2004 07:41 AM:
# Greg Robinson said on April 8, 2004 08:44 AM:

I hit this wall when remoting DataSets to a remoted server (hosted by IIS).
Whats i very strange is a can remote a DataTable across the wire and see changes made in the remoe server back on the client; however I cannot see changes to a DataSet I remote.

What do most folks do: Return the DataSet from the remoted server and then doa Merge on the client?

# Manish Jadhav said on May 13, 2004 11:02 PM:

I ran across this issue when I was trying to send a DataTable back using remoting. Finally I had to give up and send a DataSet ... which I think is an overhead I did not want.

Manish Jadhav

# Greg Robinson said on July 13, 2004 01:54 PM:

Awesome. Our entire dal is built around returning datatables, objects and datasets. I just discovered you cannot remote datatables.

# Tim Black said on November 6, 2007 11:32 PM:

Why use datasets and datatables.  Use CSLA instead.

Leave a Comment

(required) 
(required) 
(optional)
(required)