DataSet vs Custom Entities
In these days I’ve read many different opinions about DataSet and Custom Entities. Here is my personal point of view.
DataSet
DataSet are not particularly optimized when you serialize them with either XmlSerializer or Formatters runtime serialization, at least until the release of .NET Framework 2.0...
By default XmlSerialization of DataSets is a little bit fat J, because of its Schema, Data and DiffGram representation. To tell the true we can refine XmlSerialization of DataSet implementing IXmlSerializable interface in custom DataSet or typed DataSet.
On the other side re-implementing IXmlSerialization is not always trivial and sometime it’s simply too expensive if compared to the goal we’d like to achieve.
In order to use a DataSet inside the presentation layer, we need to have knowledge about data structures (i.e. tables, columns and rows hosted by the DataSet), so we don’t have real abstraction from the data layer.
Anyway a DataSet makes easier to develop data binding code not only in ASP.NET but above all in Windows Forms apps.
From a Web Service point of view a DataSet fights with SOA, with WS-I BP1 and with any other kind of SOAP node that’s not .NET based.
Typed DataSet
A typed DataSet allows us to handle data in a more abstract way, even if there’s a DataSet under the cover, we can think and write code in terms of Objects (rows) made of Fields (columns) grouped in Collections (tables).
Thanks to the handling of data as collections of typed objects we can trap errors while in compile-time rather then in runtime.
For instance if we use a classic DataSet on a table that has an integer idCustomer column:
ds.Tables[0].Rows[5]["idCustomer"] = 5;
ds.Tables[0].Rows[5]["idCustomer"] = "Foo";
we’ll get an exception on the second row just during runtime.
With a typed DataSet:
ds.Customers[5].idCustomer = 5;
ds.Customers[5].idCustomer = "Foo";
we’d have a compilation error. It sounds better of course, especially when on the presentation layer there’re developers that have a little knowledge about the data structure.
From a data binding point of views typed DataSet are equivalent to classic DataSet.
On the other side using a typed DataSet doesn’t change the size of the serialization result.
A Web Service based on typed DataSet is still not WS-I compliant and not SOA oriented.
Anyway we can override its XmlSerialization, re-implementing IXmlSerializable and customizing the auto generated WSDL, in order to make it readable by other platforms, for instance Java with AXIS even if we’ve no guarantee to be WS-I BP1 compliant and SOA designed. I always say that we’re not obliged to design and develop services WS-I BP1 compliant and/or SOA architected above all if we don’t need it… you know, but I always also say that services world is following the SOA and WS-I way, are you sure that your services won’t do that sooner or later?
Custom Entities
Custom Entities are usually slim, from an XmlSerialization point of view, and there are also tools, like System.Xml.Serialization attributes, to make it even slimmer.
We’ve to pay the due to fill the entities with our data, being careful of not building monster with multiple heads, with GB and GB of RAM filled with data that should be kept inside the DBMS engine. Remember that custom entities are the containers of small instance data and not a replacement for your DBMS, like DataSet as well, of course!
In order to develop WS-I BP1 and SOA compliant services, custom entities are the right choice. It’s enough to design in the right way your messages, as XSD, and to describe your contracts with custom WSDL.
We’re able to easily data bind a custom entity in ASP.NET presentation layer; on the other side it’s not so easy or quick to bind a Windows Forms presentation app.
So, what’s the best choice?
The answer is: “It depends J !”
Why “it depends”?
First of all I think that we need to identify the target of our discussion:
1) Windows Forms application inside a LAN with 2-tier architecture (client/server)
2) Windows Forms application inside a LAN with n-tier architecture
3) ASP.NET Web Application
If you’re in the first situation … don’t care about that, just use a DataSet. Anyway think about the reasons that made you do not choose n-tier architecture ….
In the second case it’s better to consider custom entities, not only from a bandwidth point of view (remember that custom entities are generally smaller than DataSet) but also from an architectural point of view (only data layer should have knowledge about your real data structure) and, if you’re using Web Service, above all from a SOA and WS-I point of view. On the other side you’ll pay your choice in terms of data binding pains. In fact data binding in Windows Forms using a custom entity is not easy as with a DataSet.
In the last situation I’d like to decide carefully every single time I need to make this kind of choice. It depends on the size of your data, of your database, the portability of your architecture from ASP.NET to other presentation tiers, etc.
We also need to think a bout who will write the presentation layer:
1) People with knowledge about the data structures
2) BIZ and DAL are written by people different than the presentation layer group, so they have different knowledge about the data structures
In the first situation we’re free to choose the best solution for our project. In the second case we need to keep in mind that an object model (with VS.NET intellisense) is easier to use than a general purpose DataTable in a DataSet, so at least a typed DataSet or a custom entity will probably be my choice. Remember also, as I’ve already said, that data layer should be the only one layer to have complete knowledge about the data structure.
Then if we need to make our data available through web services we need to care of the real targets of our services:
1) Only a .NET node
2) Any kind of SOAP node
3) Any WS-I BP1 compliant node
In the first situation we need first of all to think about why we choose a Web Service … I mean: if you need to speak from .NET to .NET Web Services are not the only way we have. We’ve also .NET Remoting, Serviced Components, SOAP Services based on WSE2, etc. Of course may be that a Web Service is the right choice for your project, nut think about that, don’t just use it as a default answer.
By the way if we decided to use a Web Service to decouple our .NET layers, but we know that .NET will always be the only choice in our life J … sometimes we can think about using DataSet and/or typed DataSet in order to have easier access from the presentation layer, to data binding features. On the other side keep in mind that Web Services that handle DataSet and typed DataSet are verbose.
In the second and third case I always choose custom entities because this is the only way to be really interoperable and WS-I BP1 and SOA compliant. In the third case I always start designing messages (XSD) and contracts (WSDL) and just at the end I develop the underlying code.
At least we need to think about who will query the BIZ layer:
1) ASP.NET
2) Windows Forms
3) Both of them
4) Many different kind of apps
I’ve already showed you my opinion for the first and second case.
In the third situation custom entities are more expensive, in term of code to write, than DataSet or typed DataSet, but are more portable and somehow maintainable.
In the fourth case is often mandatory to make an abstraction over the data structure, in order to make possible to use the BIZ layer with many different applications and types of applications.
Anyway I really don’t like to have a default answer for any situation; I always prefer to think carefully about all different pros and cons, to always try to get the best.