CODEWITHSUNDEEP
.netstored-proceduresdatatableado.netdataset
nullexception
nullexception

Reputation: 131

Confusion about the appropriate use of datatables and datasets

I've been doing some research on whether what best practice is regarding the use of datatables and datasets and I haven't found any real conclusive answer. Both work for what I want to do but while there is no conclusive answer, the general consensus here and everywhere is that datasets should be avoided.

Basically, what I want to do is to retrieve data from the database using stored procedures. Each of the stored procedures pulls data from different tables and may perform some joins. This data is then displayed in a windows form. The user will use this data and then either add a new record or update an existing one in the database.

One method that I'm familiar with is to make separate database calls, storing the results in a datatable and then working with this object to display it on the screen. This is done using ADO.net. This works. Also, using a dataset to return all this data from one database call (one stored procedure) works too. But apparently, this isn't the ideal or most efficient way of doing things? I'm not too familiar with LINQ but this seems like another method of retrieving data.

I suppose this is broad question for a specific problem. While services cannot really be used at the moment, the ideal solution would be to design the system so that we could make use of web services in the future.

I kinda feel like I'm over analyzing things at this point and I'm pretty sure I've managed to successfully confuse myself when it comes to all this. I would really appreciate comments and thoughts on this issue.

Upvotes: 3

Views: 223

Answers (2)

Marc Gravell
Marc Gravell

Reputation: 1062770

One time that DataTable (etc) certainly is helpful is when writing a general purpose non-schema-specific tool (where the query and therefore scheman is only known at runtime) - an ad-hoc reporting tool, maybe, or something like SSMS.

DataTable is also convenient for feeding SqlBulkCopy.

A lot of folks argue that for everything else, regular c# classes are preferable. Certainly it is very rare I see DataTable in production code these days. However, it can work.

Personally, I like POCO + "dapper", which takes all the binding work away (including for SPROCs), but works nicely with typed class models, without the overhead of full ORMs.

Upvotes: 3

competent_tech
competent_tech

Reputation: 44931

If you have services anywhere in your future, then you should immediately abandon datatables and datasets and create business classes (aka data transfer objects or DTOs).

This is the correct long term implementation if you have any intent of ever moving the data over a service.

Upvotes: 3

Related Questions