Like the Recordset in ADO, the ADO.NET DataSet object is one of the most loved and used managed data types. Not only is the DataSet a rich and powerful programming interface, it also enjoys very special treatment from data-bound controls. The Windows Forms DataGrid control, for example, can automatically navigate through the various tables of a DataSet. With a little code, you can obtain the same from a web DataGrid, too.
It is common practice to create .NET XML web services with methods that accept and return DataSet objects. As a developer, you reason in terms of a powerful and feature-rich object; the surrounding framework completes the scenario by letting you connect it to a variety of controls in a pretty seamless way. As a matter of fact, the DataSet shines. But is all that shines necessarily gold?
The key thing going on here is that the DataSet is a platform-specific object. On the other hand, the web service is a cross-platform tool. This means that a web service created using the .NET Framework can easily be consumed by clients living on non-.NET platforms, including a Java platform.
Web services are known to be interoperable components, but not at all levels. Interoperability is guaranteed at the XML/SOAP level, but this is not necessarily good news for all developers. A much better form of interoperability is the toolkit interoperability, in which the schema of involved objects can easily be adapted to the caller platform. The DataSet is a weakly typed, polymorphic type whose actual layout can be fully determined only when the object is filled with data. This makes it difficult for a type converter component to analyze its general-purpose schema and come up with a class. Note that this is a general problem that also exists in the .NET platform but that finds a slick workaround in the .NET Framework.
To make your web service really interoperable at a level higher than the raw XML API, you should avoid using DataSets. If you find it a really comfortable type, opt for a typed DataSet instead. A typed DataSet provides a strongly typed interface, which simplifies the job to other platforms' class builders. A class builder is a tool that reads a WSDL file and creates a corresponding class. A class is normally an offline tool; in .NET, it is the wsdl.exe tool.
As an alternative to using typed DataSets, you can opt for a collection or an array of custom types. For example, if the method is expected to return all orders for a given customer, you can pack all the orders in an array. You represent each order with a made-to-measure structure. The .NET web service infrastructure-specifically the code behind the WebMethod attribute-takes care of serializing the array to XML.
The XML representation of an array is much simpler to parse for a class builder and it also significantly reduces the number of bytes transferred across the wire. The only problem left is with data binding. An array or a collection is not immediately bindable to all .NET controls. The .NET class builder builds a client-side representation of the custom class but, for simplicity, it renders all data members with fields instead of properties.
Public Class Person Public Name As String End Class
A field is simply a public property; a property has get/set accessors. You must replace the code above with an equivalent code that uses properties with get/set accessors.
Public Class Person
Private _name As String
Public Property Name As String
Get
Return _name
End Get
Set (Value As String)
_name = Value
End Set
End Property
End Class
The class declaration is normally found in the reference.vb file generated by the Web Reference wizard in Visual Studio .NET. Once you have modified the reference.vb file, recompile the project. The data binding will now work just fine.
Dino Esposito is Wintellect's ADO.NET and XML expert, and a trainer and consultant
based in Rome, Italy. Dino is a contributing editor to Windows Developer
Network and MSDN Magazine, and the author of several books for Microsoft
Press including Building Web Solutions with ASP.NET and ADO.NET
and Applied XML Programming for .NET. Contact Dino at [email protected].
