I'm a bit confused by the Dataset concept in C# (coding ASP.NET sites, not that it matters). In my reading I'm understanding that they are used (essentially) as interfaces between my app and my data (or database). I get that. What I don't understand is some articles refer to datasets as "offline storage" where updates (inserts, etc...) are applied in batch or never, and others play more to the "interface" aspect, where reads and updates (inserts, etc...) are applied immediately to the underlining database.
Can someone please explain datasets in simple terms? Do I want to really use them? Maybe some short example cases might clear it up for me. Otherwise, I don't see why I cannot just create a simple Class that selects, inserts, updates from my database, why would I care about some XML layer?
Your wisdom is appreciated.
It is a tool, and it has some handy features - sometimes they are fine, but frankly I use them very very rarely personally - usually preferring simple POCOs via things like dapper (or your own preferred ORM / micro-ORM - whatever).
The main time that
DataTable is useful is if you are creating something that is itself dynamic - for example, like Stack Exchange Data Explorer - basically tools where the <strong>schema coming back</strong> is user-defined.
In most line-of-business software, this is simply not the case - so
DataTable is not IMO the go-to tool.
A DataSet is, from one perspective, an in-memory database. The DataSet object certainly has its uses, and can be used to increase performance, make certain tasks much simpler, etc. Whether or not to use it depends on the situation. It's a tool that works well in some cases and not as well as alternatives in others.
One example of a scenario where a DataSet is a huge performance increase is in situations where you need to make multiple computations over a set of data. I/O is still a major bottleneck to performance, and it can be the case that loading a dataset into memory, and performing functions such as Sum(), Avg(), etc using DataTable.Compute is far better performance-wise than executing multiple similar statements against a true database, requiring a round-trip to the DB server on each calculation.
That's just one scenario. In a real-life application, I had to modify a program written by a previous developer, which made a connection to a Sybase SQL Anywhere function to perform multiple calculations on a sales data set.
I re-factored it to load the data once and do all computations in memory. I cannot guarantee this type of performance enhancement at all, but the program went from taking literally over 24 hours to do a batch of calculations to under five minutes.
You could use an ORM Tool like NHibernate or Entity Framework. With this kind of approuch you just send a object of your domain (for sample:
Product) to some objects of the ORM Tool and it will save on database to you. You do not need to write a SQL command to do it, the ORM tool just do it for you easly. With an ORM you just map your domain object in a class and it will manage for you on database, like this imagem (I know it is in java, but the concept is the same for an ORM tool):
<img src="https://i.stack.imgur.com/F5LC1.jpg" alt="enter image description here">
On the other hand, you have ADO.NET internally and you can just write it, you will need to write some code, but it is not difficult.
There are a lot of reasons to does not use Dataset on .net, take a look on this article: http://www.4guysfromrolla.com/articles/050405-1.aspx
I would not use a
DataSet. In general I deal with POCO's (Plain Old CLR Object) and use a library like Dapper to
DELETE data from the database. It's so much easier to just use a basic object that mimics my database (a domain-model if you will) and do what I need.
There are a number of examples on Dapper's site that show you how to use POCO's with Dapper.
For simple projects I just leverage ADO.NET features (e.g.
ExecuteReader) off of the standard
SqlCommand object. Which also doesn't need a
a simple answer would be
Datasets are disconnected, thus meaning you have a table-like structure in memory.