I have once tried to use typed DateSets in a relatively small production application. Initially it looked like a pretty good idea, but turned out to be different. It was pretty fine for some basic tasks, but as soon as something more advanced was required, it's limitations kicked in and it failed miserably. Luckily the project got cancelled, and from now on I try to stick to a proper ORM like NHibernate.
But I still wonder - they were created for a reason. Perhaps I just didn't understand how to use them properly? Is anyone out there successfully using them in production systems?
Added:
Could you also quickly explain how you are using them?
I tried to use them as my DAL - it was a Windows Forms applications, and it would fetch data from tables into the DataSet and then manipulate with the data, before calling the TableManager's hierarchial update thing (don't remember the exact name). The DataSet had one table for each of the DB's physical tables. The problems started when I had to do something like a master/details relationship where I had to insert a bunch of records at once (one master record and several details records) into several tables while also keeping foreign keys correct.
Added 2:
Oh, and if you are using them, where do you put your business logic then? (Validations, calculations, etc.)
We use typed data sets all the time, in fact we use them as a matter of best practice. The reason we do this is to catch errors at compile time rather than using string based lookups for column names that could introduce errors at run time.
I guess, as always, it depends on the scenario and whether you gain any advantage for using them or not.
Normal Row Reference:
oRow["row_pk"]
In a typed data set it now becomes:
oRow.row_pk
Our data sets usually match the database scema, we use DataAdapters to update the changes to the database using stored procedures. Output parameters update the data set with keys generated from the database.
Obviously you need to run the adapter updates in the right order for all the keys to generate in the right order. You also have to be careful when deleting parent / child rows, and ensure these deletes take place in the right order to prevent database exceptions.
Back when .NET was still 1.1 I read a book on ADO.NET by David Sceppa, this opened my eyes to what can actually be acheived, and simplified my DAL a lot (using typed data sets). There are a lot of techniques in there that can really help improve your code, I'd highly recommend it.
They were useful for me to create XML documents to send to a web service. The client defined the expected data as typed DataSets and that made it very simple to create a DataTable in memory and get the XML representation.
Now, for real database access... I use my own DAL, I agree with you - DataSets are incredibly limited.
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