Should I expose a strongly typed dataset from a webservice and bind it directly in a client? or are there more sensible ways for asmx web services? I am doing CRUD operations (Create, Read, Update, Delete).
I find working with datasets to be frustrating and difficult to work with when for example when inserting into a table within it for instance. It doesn't seem logical to ship a whole dataset to and forth when only inserting one record or when only getting one record from a particular table within the dataset.
Is there a better way?
Should I perhaps be converting to objects and use objects over the webservice? Doing conversions all over the place to get objects passed around is perhaps just as tedious?
It depends on your interoperability requirements. Although it's entirely possible to process the DataSet XMLs from practically any environment it can get unwieldly. If you're not interoperating I'd definitely recommend the typed dataset route because it's insanely simple to use from C# and "just works".
I would say opt for objects, DataSet's can get kinda messy. Objects can be a lot cleaner to look at, and of course debug.
Be careful when working with abstract types though as they can be a bit of a pain to serialize if you have collections based on an abstract class/interface. I had problems with this in the past, however, I found a solution.
Note that the Dataset is specific of .NET. If you want to make you API interoperable, you should stick to elementary datatypes and constructs (otherwise, the situation is likely to be cumbersome for the non-.NET developers).
Then, web services aren't designed to pass large objects around in a single trip. If your dataset contains more than a few hundred KB, you are likely to end-up with client-side or server-side HTTP timeouts (considering default settings).
For CRUD operations, I would simply suggest to expose each operation directly through the WS.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With