我从未正确地使用过DataSet（连接到SQL Server），但它曾经对某些特定需求很有用。我发现DataSet和DataView是实现数据/BLL层的相当方便和功能强大的基类，直到我能够有所思考地放置某些东西。如果什么都不考虑，那里面有很多功能性。

无论是好是坏，答案就是简单性。当2.0框架推出，并在其中包含了TableAdapters，就变得非常容易获取基本的CRUD类型应用程序，甚至是显示数据的首页。只需连接到您的服务器，将表拖到您的位置，结构就建立好了，包括外键/主键/唯一键引用。需要对这些数据进行更新吗？使用向导，指定现有的过程，或让向导为您生成adhoc/stored过程。

然后你就完成了，将其连接到GridView，你可以快速地完成许多操作：重新排序、重新查询、在离线状态下编辑多个记录，并以单个或批量方式进行更新。在处理需要快速完成的项目时，这种便利很难忽视。另外，以这种本地的“DataTable”格式拥有的便利也变得对于XML乱搞操作非常有用，因为DataSet模型在许多方面下使用XML。

I will admit that I have not checked out the latest versions of the ORMs out there, and I m not sure if there is a wizard for LINQ that will do this much within a few clicks. And most people are a little slow to adapt newer technology as is, so it easy to see how it is still being used heavily.

Seeing that new Dynamic Data Service site/project is built off of LINQ to SQL or LINQ to EF, I think the tide might finally change to the newer model.

I think the biggest problem with datasets is they basically encouraged you to create a dbms in memory. I love the way Linq/entities cover your data needs and they rely on standard .Net collections classes and generics to work.

话虽如此，我不会否认能够动态读取未分类数据并在内存中应用关系等功能的力量，这仍然非常非常强大，具体取决于您的情况。

喜欢数据集的三个理由：

• For winforms they support databinding/filtering most orms don t
• Many 3rd party tools (esp reporting tools) have built in support for datatables/sets and not for plain objects..
• While debugging you can right-click on a filled table and view the contents. This is a real time-saver.
  

总的来说，它们拥有很多功能。虽然我不喜欢适配器。我通常会编写自己的数据库适配器。

I think I m in the same boat: I very rarely use datasets, and I certainly don t claim to be an expert on the adapter model (I think "Fill" is the only method I have really used in production) - but they do occasionally have some uses. For example, if you need to execute some ad-hoc SQL code, can t predict the schema (and so ORM doesn t help), and don t want to mess with IDataReader etc for a simple, small set of data.

Other than that (i.e. most of the time), I prefer standard classes - either ORM or manual.

The most publicised use of DataSets is to create an in-memory copy of the database. I found I never used it for this, even with .NET 1.0. The disconnected model was always innappropriate in a multi-user environment.

If you ignore relational databases altogether, there are still uses for DataSets:

• If you re writing a forms application that is to load and save data into a file, you can define a typed DataSet, then load and save it using the XmlDataDocument class.

• Crystal Reports can generate reports by reading in-memory DataSets. You can create a typed DataSet just for one particular report, and use the .NET language to write complicated business logic to populate this DataSet. This saves you the from implementing the business logic using the Crystal Reports functionality (which can be a really difficult task)

• You can attach a DataGridView to a DataSet with one line of code to get a crappy user interface, which nevertheless might do the job you need. Good for things like in-house testing tools. (Not good enough to ship to a customer).

I find it so nice for these tables (not so much) which sure are not going to change on a long time like item lists or some kind of historical data.

I use Typed DataSets for a really low lever orm. I know it s not half as good, but try explaining that to the big shots..
So instead of changing the world and introducing some non-microsoft oss tool (Or finally migrating from .net2.0 to 3.5, and use l2s or ef), I just use a dataset to keep my query results, and easily bind them to grids, textboxes and comboboxes where needed. I find the ability to later use something like

MyDataSet.MyDataTableRow row = // whatever
if (row.Price > 100) // do something

very useful.

For Pros Programmer. They use DataSet because the DataSet object is designed to encourage the use of optimistic concurrency for long-running activities, such as remoting data and interacting with data.