I was wondering about that, too. As a user I want to know about data entry problems as soon as possible, not when I have done further keying and press Save.

>How do you handle database constraints? Are you handling it tightly on the server, but loosely on the client?
>
>>We pretty much use our DataSets only as a way to pass around the data. We don't use the relationship features, or make use of primary keys ... that just causes headaches, IMHO. So basically, it's just a bunch of collections. Pretty easy to get your head around that I think.
>>
>>~~Bonnie
>>
>>
>>
>>
>>>Heavy in the sense of the size of the object, the amount of memory it use and all the process it need (initialization, etc.) It's OK if you plan to use the majority of the built-in functionality, but if you use a fraction of it (as it's often the case), a custom object will have a far smaller footprint.
>>>
>>>I never used GetXml(), but I'm curious to look at the resulting XML. Not sure that it won't be bloated.
>>>
>>>I must confess that a part of my negativity against DataSet come from my misunderstanding of it. I've used them in my last project and I had a very hard time trying to have it behave the way I wanted it to behave. Got stuck in incomprehensive error messages and trying to learn the DataSet class and all it's related classes is a major project all by itself. I finally got it working, but I had the strange feeling that it did "magic" stuff that I didn't understand. I hate it when I don't know the internals. At least when I build my custom objects, I know how they work (sure hope so!).
>>>
>>>>That's a common misconception. Heavy how? Across the wire? You don't send the DataSet across a Web Service, you send MyDataSet.GetXml(). It's not as heavy as the DataSet itself (no schema gets sent and only the actual data that is present gets sent). Plus, it's only a string of XML. Anything can consume it, not just the .NET world.