Worth the hassle, or is it just better to write your own data access classes?

5/19/2008 8:25:43 PM

i just got done on a .netcf project and in that case it was best to write your own - on a desktop i probably wouldn't though

5/19/2008 8:27:05 PM

SubSonic ftw

[Edited on May 19, 2008 at 8:30 PM. Reason : or LINQ]

5/19/2008 8:30:31 PM

Unless you're going to use a lot of the features of a dataset (the sorting, the DataTable relationships, etc.) I've seen it to be more bloated than necessary.

I've found more success using some sort of base entity class along with a strongly-typed collection class (if you're using 2.0 or greater you can be much more efficient using generics).

SubSonic, LINQ, or nHibernate...I prefer nHibernate.

I will say that I have used Datasets in cases where I had unrelated tablular data (for instance results from an adhoc search that would not directly map to an entity/business object).

[Edited on May 19, 2008 at 9:23 PM. Reason : case for DS]

5/19/2008 9:15:38 PM

really, the only "benefit" i see from the dataset is that I don't have to write accessor methods or a class for what the tuple represents, aside from easy integration into forms with binding. The "update" methods are unwieldy, to say the least.

Why the hell would anyone use a dataset in the first place? What is "good" about them? Seems to me that you have to keep up with two definitions of a database with that damned thing.

5/19/2008 9:38:58 PM

dlinq (or linq to sql) depending on the application. Then ofcourse add caching and offline syncing. and do all of that through a webservice...

but it really depends on what you are doing...

5/20/2008 2:47:10 PM

subsonic is a lifesaver

5/20/2008 4:57:12 PM