DataSet vs. Collections

Comments

# Hannes Preishuber said on August 4, 2005 05:05 AM:

I tryed to use the smaller datatables to transfer data between Webservice and application. I think its a good and fast idea. Should be possible in 2.0
but doenst work cause of some type problems in the wsdl file

# karl said on August 4, 2005 07:11 AM:

Imma give myself a shameless plug here since i do think it's pretty relevant...

For anyone knew to the concept of thinking of their code in terms of the business rather than programming artifacts, check out:
http://msdn.microsoft.com/asp.net/default.aspx?pull=/library/en-us/dnaspp/html/CustEntCls.asp

# DinoE said on August 4, 2005 07:18 AM:

Hi Karl,
thanks for providing the link here. I didn't know of your work when I wrote my article. It would certainly have been a great one to mention and quote. Great job, by the way.

# Domenico Loschiavo said on August 4, 2005 07:37 AM:

HI Dino,
Just yesterday I read your article on MSDN magazine.
I prefer to use collections & custom objects rather than dataset in my applications. I agree that it takes longer time to be developped, but, in my opinion, resulting flexibility pays the extra work.
Moreover, defining a good serialization schema, I used the same object also inside SQL server 2000 stored procedures. This makes the application more easy to be mantained, without a significant performance loss.

# Karl said on August 4, 2005 08:37 AM:

Thanks Dino :)

I meant new instead of knew...should hold off 'til after sunrise to post :)

# Cibra said on August 4, 2005 09:53 AM:

Hi Dino, I prefer to use Datasets instead of custom collections. The first one gives you some advantages on the fly, for example, it allow you to order or filter rows.
Also, in NET Framework 2.0, the datasets were optimized to work faster.

# Dave Truxall said on August 4, 2005 12:01 PM:

In our current project (.Net 2.0) we are using Typed Datasets in a Smart Client. It allows us to cache a fair amount of data locally on the client to handle offline situations, and also allows us to treat the dataset like a small local database without the need for an actual database on the client side.

We made the typed datasets from .xsd files using xsd.exe, not from the dataset document in the IDE. Creating the typed datasets this way does not generate all of the database-related code (embedded sql statements, data adapters, etc) and abastracts the dataset object much better from the data layer. The typed dataset is much lighter in the amount of generated code and still has all the benefits of being strongly-typed.

I did read your article, and I think it is a case-by-case decision whether to use typed datasets or custom objects based upon the business needs of the problem the application solves. I have created solutions both ways, and I think they are both good tools when used appropriately.

# Jeff Parker said on August 4, 2005 01:45 PM:

Honestly I think Datasets and collections all have thier own place. It is up to the programmer to know the difference. Typically when dealing with a database I would use either a dataset or data reader. Again depending on which one best suits my needs for the task at hand. I almost never use strongly typed datasets though I just really do not like them.

When I have used collections that I build myself there are situations that just scream collections. For example we have a customer that places their orders with their own home grown EDI type format but basically it is just trasfer for flat files the first line of the file is a header and every line after that is data. 17 different types of files we get in and send out to them but all that same format. So make one base class that opens reads and can write the file, also reads the header. Then create a collection that way you can for each line item in the file and so on. However once we get the file in we pop it into a database the collection also populates itself from the database as well it can supply file path or database in overloaded constructors or blank constructors let guys create empty collections. Also since these collection also need to be processed in certain orders adding custom sorting and things like that was a plus also overriding the tostring methods on each line item to spit out the line in the correct standard format, and also override the ToString method of the collection to spit out a exact file complete with header. This whole thing screamed collections. Where a DataSet would have really made this cumbersome. However sometimes database access screams dataset. Especially when you have a lot of binding going on or paging etc. I do not think there is a vs between the two I think using the right tool for the right job is more important.

# Chris Wallace said on August 5, 2005 07:44 AM:

I wonder how many people were actually working with Beta 1 of .NET? I imagine most of us didn't really start playing until closer to the RTM which puts Datasets @ 3 years old for us.

# Sean Chase said on August 6, 2005 12:35 PM:

Personally, when .NET first came out I was using DataReader almost exclusively. Then after figuring out that they were dangerous if you don't close/dispose them and they weren't meant for passing around between layers (or even functions for that matter), I went to exclusive use of the DataSet. I was shocked to see that it wasn't really a performance hint (I know that's arguable). But, I quickly started to hate how it was a like a loosly-typed ADO Recordset (row["customerid"])...So I found the XSD designer and started making typed-DataSets. For a long time I was a typed-DataSet freak, and I still like them, but....I changed my opinion sometime late last year. Typed-DataSets don't work out well for an object model IMO. They are are large objects and the trade-off is that they give you a lot of functionality: XML, Diffgrams, relationships, null checks, schema, etc. As my object model became more fleshed-out, I found that the ability to extend the typed-DataSet just wasn't there and I've gone the "custom class/custom collection" route and haven't looked back. Besides, as someone already mentioned, generics will take a lot of grunt work away for simple tasks like creating List<Customer>.

Great MSDN article by the way Dino.

# DinoE said on August 6, 2005 12:42 PM:

Hi Sean,
your story intersects mine in several points. I'd even say that we share the same experience to a large extent. I couldn't agree more with you.

Another point that I like to make here answering other comments is that there's no war between collections, DataSets, or typed DataSets. As Jeff clearly wrote, each one has its own place and it is up to you choosing the best for you.

They're tools for us to use; they're not robots making the work for us.

BTW, remember these two cents of mine when you move on to choose between SqlDataSource and ObjectDataSource in ASP.NET 2.0. To date, they appear to me like the projection of DataSet and custom collections.

# Damith said on November 26, 2007 05:02 AM:

i wont to know how build 3 tire Application in Asp.net (Separeate Project Like Biz,Data Access Layer like wise) and Better to use Type Data set and Collection

which one you recommend to buil Project

i will hope you immediately response me

thank you

Leave a Comment

Title (required) 

Name (required) 

Your URL (optional)

Comments (required) 

Remember Me?