June 2, 2004
@ 08:46 AM

Ted Neward has a crusade against DataSets going on on his blog. At this point in time, I really only ever use them inside a service and only at times when I am horribly lazy or when I code under the influence. Otherwise I just go through the rather quick and mostly painless process of mapping plain data structures (generated from schema) to and from stored procedure calls myself. More control, more interoperability, less weight. I really like when my code precisely states how my app interacts with one of the most important components: the data store.

I don't even use DataSets on ASP.NET web pages anymore. The data binding logic allows to bind against anything and if I have a public or protected property "Customer" on my page class that is a data structure, I can simply have an expression like <%# Customer.Name %> on my page and all is good. Likewise, a DataGrid happily binds against anything that is an ICollection (Array, ArrayList, ...) and the DataGridItem.DataItem property will then contain the individual element.  It's just that the design-time support in VS.NET is very DataSet focused and messes things up when you click the wrong things. 

DataSets are really cool for Windows Forms apps. By now I've reached a point where I simply conclude that the DataSet class should be banned from the server-side.

Wednesday, June 02, 2004 6:23:08 PM UTC
For those who don't or can't use XSD contract-first...

If you are using Typed DataSets inside your service, Reflection can be used to generate code for an interoperable strongly-typed array, where each array item maps to a strongly-typed DataRow. Additionally, it is straightforward to generate the functions to map between the two structures.

Note that, in .NET 1.1, the Web Service proxy generated from the WSDL will expose the data in the strongly-typed item class as Fields. This is inconvenient in many .NET scenarios, since DataBinding uses Reflection to search only for public Properties.

However, once you have the code generation mechanism in place, it's straightforward to generate suitable client-side code.

I recommend CodeSmith for general-purpose code generation.
http://www.ericjsmith.net/codesmith/

For improved XSD-based code generation (relative to XSD.EXE):
http://weblogs.asp.net/cazzu/archive/2004/05/14/XsdCodeGenTool.aspx

Incidentally, how about MS making XSD.EXE and WSDL.EXE (and newer versions in WSE2 RTM/.NET 2.x) available as GotDotNet community projects?

Cheers,
Martin
Martin Naughton
Thursday, June 03, 2004 3:22:22 AM UTC
I think the best way to think about when to use (or better when to never use)DatsSets is based on the Journal2 article (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnmaj/html/aj2intro.asp) on Service-Oriented Architecture: Considerations for Agile Systems.
The coarse grained services should never use them. If there are some use cases that allow them, those would fall into the fine grained, tightly coupled and internal only services.
And yes I love DataSets on WIn forms, especially with ErrorProvider
Thursday, June 03, 2004 8:41:05 AM UTC
So, if you want to build a winform app, you return datasets from your services?

What I don't get is that I want a middle tier that can be used from multiple presentation layers, and having to build it one way to talk to winforms and in another to talk to asp.net does not make a lot of sense.
Peter
Thursday, June 03, 2004 12:20:16 PM UTC
Only INSIDE the Windows Forms app. Never on the service edge.
Clemens Vasters
Thursday, June 03, 2004 6:31:42 PM UTC
You mean you return a simple type in the webservice and then load it in a DataSet in the client?

How to you handle updates? You don't allow updating because you'll want to mine the old values 5 years later ;)?
Peter
Thursday, June 03, 2004 7:12:17 PM UTC
Dataset also make sense ( from my view) in asp.net.
One of the main reasons is data caching. Data which less changes or often requested should be stored in the data cache of asp.net. Datasets are an easy way to do that. Also for future asp.net development datasets are good for comptibility with future Data Controls
Tuesday, June 08, 2004 2:11:02 PM UTC
One of the areas in which I use DataSet in an ASP.NET application is when I need DataViews/Filters. They are extremely powerful and will be very difficult to do using data structures. For most other work I simply use a DataReader. If I need some form of in-memory persistance but don't require the full capability of a dataset I tend to use structures.
Thursday, June 10, 2004 5:26:03 AM UTC
I'm using DataSets with the Data Access Application Block in my DAL's. In Business and Presentation Layers i mostly use custom collections and my own business objects.
Saturday, June 12, 2004 8:59:43 PM UTC
I don't even use DataSets on Windows Forms or for ASP.NET Caching. After the initial learning curve business objects to me are easier and more robust to use. Just like on ASP.NET, business objects can be bound to Windows Forms controls. As long as your objects are serializable you can stick them in the ASP.NET cache. Since in Windows Forms the data comes from the controls as well as loads the controls being able to put business logic in the properties that are bound makes them far superior to DataSets and they are much leaner as well. Take a look at Rocky Lhotka's book, very nice Business Object Framework (C# version of the book coming soon for those odd people that have a problem with VB.NET :) ).
Sunday, June 20, 2004 7:56:58 PM UTC
Clemens, what do you think about applications models like: TaskVision, WeRock.247, etc. all handle data as DataSets. Personally I not always agree with this choice, even if I'm not doing a crusade :-) against DataSets, but I'm interested in your opinion. Microsoft seems to push those apps as "models" ... what's your opinion?
Comments are closed.