Well, I could see that happening in my situation too. My business objects all use an internal DataSet, so Customer, Invoice and Lineitems for example all have their own DataSets that may then have multiple tables in them.

However, DataSets don't incur that much overhead to worry about it. THe overhead comes from connecting things together - tables to the dataset, relations etc. and if you serialize that the whole thing needs to serialize.

The XSD generated classes is pretty heavy though mainly because the first time you use the DataSet or load something into it it creates everything - an empty table for each in the dataset the objects etc. It's not a ton of stuff, but this code needs to compile too with the JIT the first time it loads so there's additional overhead.

I can live with that I suppose because I can always use the a regular dataset when I want and a typed dataset when I need it only (my bus object allows assignment of the DataSet and then it uses the DS wtih a default set in the constructor).


Biggest thing I don't see is how to keep things in sync without having to manually remember that I changed the database, now I have to change the XSD/DataSet class here.

I'll respond to another of your messages to keep focus on this <g>...



+++ Rick ---





>Hector,
>
>>Opening a form with many of them (say 30) takes a loooong time at design time in VS.NET<
>
>Why in the world would one Form have 30 DataSets?!?! Seems a bit excessive. We have DataSets that have a lot of Tables (one has close to 100 tables), but pretty much every form only has one DataSet (a few exceptions might have two or three). Secondly, why drop the DataSets on the Form in the Designer? Just add them programmatically with all the other member declarations.
>
>>>Another issue that they ran into with typed datasets was that when there were too many datasets (say 15) defined in a web service, the web service took a rather long time to instantiate.<
>
>Our WebServices are pretty much wrapper classes to the server-side BizObjects, which do all the dirty work. Each WebService really does nothing more than call the BizObject and return one DataSet as XML (or if it's an update WebService, it sends one DataSet as XML to be updated by the server-side stuff). Even so, if our BizObjects were loaded down with multiple DataSets, we'd probably run into the same issue, but they aren't ... it's still pretty much one DataSet for one BizObject.
>
>>>In summary typed datasets have been a pain in this application with little benefit, BUT a lot has to do with the way the application was designed/coded initially, not with the typed datasets themselves<
>
>Sounds like you need to apply a little refactoring. <g>
>
>~~Bonnie