My love affair with datasets fell away as I improved as a programmer... We initially used data-sets in a failing project years ago early in the .Net days. It was a nightmare to maintain - and the underlying database schema wasn't settled. Due to the lack of strong typing in data-sets a change in column names often went undetected and caused all sorts of issues down-stream. Then there were several memory leaks that datasets were responsible for. And datasets are so heavy - our application was more memory intensive than Outlook (and that's saying a lot) - and we had many complaints from users. We also found they caused deadlocks in the database even with just a hundred users or so.
Never again - we went back to straight ADO.Net into plain old class objects (POCOs), and the simplicity was a breath of fresh air. Initially we missed the niceties of datasets - get / set xml, sorting, and filtering. We quickly created helper classes / code snippets to add these things. Data-binding has never been particularly compelling in .Net (maybe I'm just still scarred from the VB6 days?) - but it simply never 'worked' with validation anyway. And we realized the real issue was proper separation of concerns - we were linking data-base objects directly to the UI; although admittedly client/server had been all the rage in the years before. We'd written a 'data-driven application' that Microsoft seemed to railroad you into (probably to keep it RAD like), but we weren't designing things properly. Essentially the application just seemed 'clunky'. With a major version release we redesigned out software from scratch with proper logical layers and separated concerns. While it initially took longer to develop, in the long run we had much more agile and maintainable code. Our IT manager even made a point to other teams that our software's maintenance cost was the lowest even though our project was one of the largest. I then left the company onto greener pastures... but a funny thing happened the other day. I met a lady in the pub who turned out was one of that companies clients. I mentioned I wrote that piece of software, and she said that it's still used today, and holds its own - even though it must be over 5 years old now. Back on topic: These days with LINQ I'm not sure datasets give you functionally more anyway. These days I still tend to use LINQ2SQL for its straight-forward data-access although I'm about to try my first project with EF4.1 code-first. I wouldn't dream of going back to datasets. Nathan. On Thu, Jul 21, 2011 at 8:24 AM, Greg Keogh <[email protected]> wrote: > Chaps, your comments are interesting and perhaps make me feel not so guilty > for using System.Data classes in these modern times.**** > > ** ** > > I’ve only used netTiers and EF4 in recent years, but deep down they all run > a SELECT statement, loop through the rows and move the columns into > collections of objects with matching property names. In the early .NET years > I wrote my own code to do that, and I know VB6 developers who are still > doing it.**** > > ** ** > > The classes and collections returned by netTiers implemented all of the > interfaces I like in System.Data. The EF4 equivalents do not seem to. So > where does that leave me? I fall back to the “convenience” of System.Data > and I feel guilty, but perhaps I shouldn’t. Maybe no one is game to admit > that EF4 is a bit immature.**** > > ** ** > > I’ve had no reply from the EF4 MSDN forum yet.**** > > ** ** > > I will continue to send DataSets to pick lists and grids in my UI. However, > I do perform updates and deletes using the EF4 entities and context, and I’m > reasonably happy with the way it works. It’s tedious to eager load an entity > with non-tracking, send it up to the UI, edit or delete it, then attach it > back to the context and call ApplyCurrentValues on all the entities before > saving it.**** > > ** ** > > netTiers is not regarded as a big player in the ORM field, but my > experience so far is that netTiers is generally better than EF4 because its > entity classes and collections are completely self-tracking, and most > importantly, there is no concept of a context. The only reason I’m learning > EF4 and using it is because it’s “the latest greatest thing”. I guess > marketing does work!**** > > ** ** > > Greg**** >
