This post originated from an RSS feed registered with .NET Buzz
by Udi Dahan.
Original Post: Re: Datasets
Feed Title: Udi Dahan - The Software Simplist
Feed URL: http://feeds.feedburner.com/UdiDahan-TheSoftwareSimplist
Feed Description: I am a software simplist. I make this beast of architecting, analysing, designing, developing, testing, managing, deploying software systems simple.
This blog is about how I do it.
Following my recent post on Datasets and O/R mapping, I've received some comments and one in particular I wanted to call out.
Jacob Proffitt, the Rabid Paladin, wrote up a post on how to handle DbConcurrencyExceptions when using datasets. 4 different ways, wow. I don't think that any of them would work if the same row got 2 (or more) updates before getting sent to the database, since then we'd lose the ability to implement our nice business logic in dataset internals.
The main problem that I have with datasets is how they are used. They are the answer to databinding, sending data around (the all powerful DTO), and doing online transaction processing (OLTP), and do pretty much all of them OK in the simple case. If you are building a simple system, they're probably right for you. Unfortunately, I've seen too many projects whose requirements were quite complex and got mired down so bad with datasets that they couldn't continue. And this isn't me here, who never spent the time getting good with datasets - these were people who were VERY experienced and knowledgeable in their use.
When those same projects used different solutions for databinding/reporting, distribution, and OLTP - everything became much simpler in the common case. Complex cases that were intractable became possible.
My thanks to Jacob for making it clear how to make datasets handle common OLTP scenarios. I wonder - why didn't they make datasets do that out of the box?
Previous Topic
