Ideas about ADO.NET Datasets (an ongoing process): I recently worked my way through Shawn Wildermuth's "Pragmatic ADO.NET". Like so many other books on ADO.NET it seems to completely promote an "about-face" in the area of data access programming. So much so that I almost pictured the ghostly hand of Microsoft guiding Mr. Wildermuths keystrokes. Sort of authorship by channeling.
Over and over again this book promotes the Dataset object as almost the universal panacea for all of your data access ailments. I'd like to be fair in my opinion so with that in mind, I can say that Wildermuth does touch on a couple of valid points in which a ds might come in handy. But still I came away feeling that once again Microsoft is slaying imaginary dragons and providing solutions for problems that only arise in connection with other technologies but not necessarily the one technology that is the instrument of the solution. OK this sounds convoluted so let me clear it up.
Over and over and over I read that one ought to prefer a Dataset over a Datareader because of the cost of opening and closing a db connection when using a reader object. Can we make a mountain out of a molehill to promote our latest achievements please? Connections are pooled in most NET / SQL Server configs and therefore are faster to open and close. Has anyone mentioned that fact whilst they demote the Datareader? No! Every other author espouses the party line that you should cache datasets whenever feasible and eschew Datareaders because of the cost of opening a connection. I can see on a daily basis how developers confuse the concept of inheriting datasets with traditional OO programming.
Its a funny thing that the majority of folks who seem to adhere to the "Dateset Ueber Alles" philosophy are those authors who have come to publish only with the release of .NET. Could it be that many other experienced writers got tired of yet another Data Access Technology from MS? And if that’s what the writers feel, just imagine what the readers of these books think.
Does all of this mean that I am against Datasets? Sounds like it doesn't it? As a matter of fact I'm not. I think they make wonderful data transport objects - especially for the newer breed of "rich / thin client apps" which entail Windows apps running on individual machines that are getting data via web services. In such cases the whole concept of pushing a dataset across SOAP to the client makes a lot of sense to me. But how much of a niche is that?? Who wants to go back to installing and updating software on individual machines? Have you ever had to update your application across 500 users? I have, and even with the help of semi automated self-updates users tend manage to be just uninformed enough to require personal attention.
Have you noticed that just because ADO.NET supports OO, there are several patterns that developers follow which extend datasets way beyond the means of accessing information and turns them into quasi business objects? Yes it can be done, and yes even Shawn Wildermuth has a nice chapter on Typed Datasets, which I enjoyed reading. But in the last analysis I would tend to side with people like Martin Fowler who show that a good Domain Model of objects, while initially more difficult to establish is less difficult to deal with as the system becomes more and more complex - whereas the Microsoft espoused Dataset approach is easy to get into but more difficult to manage with increasing complexity.
2:06:08 PM
|