C# 数据集或实体数据模型

DataSet or Entity Data Model

提问by Vim

Please excuse the noob question as I am new to integrating data with my applications. I've tried to find answers on the net, but not there yet.

请原谅菜鸟问题，因为我是将数据与我的应用程序集成的新手。我试图在网上找到答案，但还没有。

I have an application I'm developing in C# on VS2010 which requires data in/out from a database. I am trying to figure out if its a DataSet or Entity Data Model I need to use when setting up a data source. My understanding was that it was the EDM which allowed me to treat tables/fields in a database as objects, but somehow it looks like I can do that with a DataSet too.

我有一个在 VS2010 上用 C# 开发的应用程序，它需要从数据库输入/输出数据。我想弄清楚它是否是我在设置数据源时需要使用的数据集或实体数据模型。我的理解是 EDM 允许我将数据库中的表/字段视为对象，但不知何故，我似乎也可以使用 DataSet 来做到这一点。

Some sources explain that a DataSet makes a cached copy of the Database which can then be manipulated.

一些消息来源解释说，数据集制作了数据库的缓存副本，然后可以对其进行操作。

Essentially my question is which should I use and what are the (dis)advantages of one over the other.

本质上，我的问题是我应该使用哪个以及一个相对于另一个的（不利）优势是什么。

回答by kaj

If you're asking what are the pros and cons for ADO.NET (DataSet) vs EntityFramework (Entity Data Model) then there is a discussion that may help at ADO.NET Entity Framework or ADO.NET

如果您要问 ADO.NET（数据集）与 EntityFramework（实体数据模型）的优缺点，那么ADO.NET Entity Framework 或 ADO.NET 上的讨论可能会有所帮助

EF will get you up and running pretty quickly but in my (very limited) experience its been a pain to maintain.

EF 可以让您快速启动并运行，但在我（非常有限的）经验中，维护起来很痛苦。

What is it that has determined that these are your only two options? There are far more available to you including many ORMs.

是什么决定了这是您唯一的两个选择？您可以使用更多内容，包括许多 ORM。

回答by Rich Turner

You have several options open to you when it comes to storing and retrieving data to/from a database:

在向/从数据库中存储和检索数据时，您有多种选择：

1. At the very simplest level, use ADO.NET to open a connection to the DB, create a command and execute it. If you expect results back (i.e. SELECT ...) then you could call the command's ExecuteReader(...). Working in this manner results in very quick execution and the minimum of overhead, but you have to do more of the heavy lifting. If your app is simple, this is probably a good way to go. If your app is, or is likely to be more complex, you may want to consider other options...
2. ADO.NET DataSets are a reasonable DB IO mechanism, particularly for reading data from a DB. However, they can be a little cumbersome when trying to update the DB.
3. You could use an Object-Relational Mapper (ORM) like nHibernate or Entity Framework, but, frankly, that often results in your learning curve increasing dramatically while you figure out how to plug together the moving parts and make them work well together.
4. You might also consider a new variant of Entity Framework called Code First (CF): This allows you to pretty much design your code and CF will generate your EDM and handle the majority of the DB operations required for you to build your system. Scott Hanselman wrote up a nice intro into EF CF.

1. 在最简单的层面上，使用 ADO.NET 打开与数据库的连接，创建命令并执行它。如果您希望返回结果（即 SELECT ...），那么您可以调用命令的ExecuteReader(...)。以这种方式工作可以实现非常快速的执行和最少的开销，但您必须做更多的繁重工作。如果您的应用程序很简单，这可能是一个不错的选择。如果您的应用程序更复杂，或者可能更复杂，您可能需要考虑其他选项......
2. ADO.NET DataSets 是一种合理的 DB IO 机制，特别是用于从 DB 读取数据。但是，在尝试更新数据库时，它们可能有点麻烦。
3. 您可以使用像 nHibernate 或实体框架这样的对象关系映射器 (ORM)，但坦率地说，这通常会导致您的学习曲线急剧增加，同时您要弄清楚如何将移动部件连接在一起并使它们很好地协同工作。
4. 您还可以考虑一个名为 Code First (CF) 的新实体框架变体：它允许您设计代码，而 CF 将生成您的 EDM 并处理您构建系统所需的大部分数据库操作。Scott Hanselman 为 EF CF 写了一篇很好的介绍。

Having used practically every DB API and ORM on Windows over the last 20+ years, I am delighted with how CF is shaping up! EF 4.3 that shipped just a couple of weeks ago includes some key new improvements to CF including migrations which allow you to handle changes to your DB schema as it evolves. I've build 3-4 systems using EF CF over the last couple of months and am very happy - it's my favorite relational database IO mechanism at present.

在过去的 20 多年里，我几乎在 Windows 上使用了所有 DB API 和 ORM，我对 CF 的形成感到高兴！几周前发布的 EF 4.3 包括对 CF 的一些关键新改进，包括迁移，允许您在数据库架构发展时处理对数据库架构的更改。在过去的几个月里，我已经使用 EF CF 构建了 3-4 个系统，我很高兴——这是我目前最喜欢的关系数据库 IO 机制。

If you want to really get into EF CF, I strongly recommend Julia Lerman's book EF CF- it's a short, nicely written, very useful guide that should take you no more than a day or two to work through the main sections of.

如果你想真正进入 EF CF，我强烈推荐 Julia Lerman 的书 EF CF- 这是一本简短、写得很好、非常有用的指南，应该花一两天时间来完成主要部分。

Hope this helps.

希望这可以帮助。

回答by Metal Latem

If your application is supporting a business application than queries get complex pretty soon. In such scenario, stored-procedures save a lot of time and are much easier to maintain and they work better with ADO.NET. In almost all scenarios, I would suggest using stored-procedures and ADO.NET. Move as much of the business rules and logic to stored procedures as you can...much easier to maintain this way.

如果您的应用程序支持业务应用程序，那么查询很快就会变得复杂。在这种情况下，存储过程可以节省大量时间并且更容易维护，并且它们与 ADO.NET 一起工作得更好。在几乎所有情况下，我都建议使用存储过程和 ADO.NET。将尽可能多的业务规则和逻辑转移到存储过程中……以这种方式维护起来容易得多。

Use Datasets (datatables) only to retrieve and read data. Any data that needs to be saved to database should be directly manipulated in the database ... no point doing it in dataset and then saving the same. In a multi-user environment it is almost always better to save the changes to database as soon as the user has clicked "save".

仅使用数据集（数据表）来检索和读取数据。任何需要保存到数据库中的数据都应该直接在数据库中操作……没有必要在数据集中做这些然后再保存。在多用户环境中，最好在用户单击“保存”后立即将更改保存到数据库。

You may (should) use business objects within the application for business-logic processes.

您可以（应该）在业务逻辑流程的应用程序中使用业务对象。

Let us take a simple example of where you are saving a Contact (name, phone, email, address etc) and then retrieving a list of contacts added today...I would suggest you do it as follows:

让我们举一个简单的例子，说明您在哪里保存联系人（姓名、电话、电子邮件、地址等），然后检索今天添加的联系人列表……我建议您按如下方式进行：

1) Adding the contact - Client (web or otherwise) collects data --> data is saved in a Contact business object --> validate Contact object --> Call repository layer to save Contact object (adding a repository layer is useful but not-necessary to keep the data layer abstract from the client) --> Repository calls the data layer to save the contact object (here a simple ADO.NET call, using Command object, can be made to call the stored procedure to save the contact in database). No dataset was used in this use case.

1) 添加联系人 - 客户端（Web 或其他）收集数据 --> 数据保存在 Contact 业务对象中 --> 验证 Contact 对象 --> 调用存储库层以保存 Contact 对象（添加存储库层很有用，但不是- 需要保持数据层对客户端的抽象）--> Repository 调用数据层保存联系人对象（这里是一个简单的ADO.NET调用，使用Command对象，可以调用存储过程来保存联系人在数据库中）。在这个用例中没有使用数据集。

2) Retrieving list of contacts -- Client calls the repository layer to get the list of contacts --> repository layer call the data layer to retrieve the data --> here the list of data is retrieved as a dataset(datatable) --> return the datatable back to the client and let the client read the data directly from datatable while rendering the data. Even a single contact can be retrieved as a dataset.

2) 获取联系人列表 -- 客户端调用存储层获取联系人列表 --> 存储层调用数据层获取数据 --> 这里以数据集(datatable) 的形式获取数据列表 -- > 将数据表返回给客户端，让客户端在渲染数据的同时直接从数据表中读取数据。甚至单个联系人也可以作为数据集进行检索。

P.S: ORM is almost always an overkill. It is almost always used because certain developers like to keep everything object-oriented...so an extra layer gets added even though it does nothing useful (IMHO).

PS：ORM 几乎总是矫枉过正。它几乎总是被使用，因为某些开发人员喜欢保持面向对象的一切......所以即使它没有任何用处（恕我直言），也会添加一个额外的层。

回答by dylanT

If you add a LocalDB data source to your project (because you want a small local database file) then when the Data Source Configuration Wizard pops up, it explicitly asks you whether you want to use a Dataset or Entity Data Model database model. Is this the situation you were facing? That was the problem I had that brought me to this entry.

如果您将 LocalDB 数据源添加到您的项目中（因为您需要一个小的本地数据库文件），那么当数据源配置向导弹出时，它会明确询问您是要使用数据集还是实体数据模型数据库模型。这是您面临的情况吗？这就是让我进入这个条目的问题。

There is no question that for an enterprise class application, or a website, you would want to investigate ADO.NET or an ORM, but it doesn't help answer this question, which has to do with what are the differences between choosing Dataset vs Entity Data Model in the wizard.

毫无疑问，对于企业级应用程序或网站，您会想要研究 ADO.NET 或 ORM，但这无助于回答这个问题，这与选择 Dataset 和选择 Dataset 之间有什么区别有关向导中的实体数据模型。

Essentially, Entity Data Model is the more recent technology. If you are unfamiliar with Dataset, then this is probably not the time to start using it.

本质上，实体数据模型是较新的技术。如果您不熟悉 Dataset，那么现在可能不是开始使用它的时候。

回答by nadavesela

But, what if you have business logic (stored procedures) which can be used in many different applications. So depends: if you make your application for different users with different backend storage, or you make many applications for users which doesn't change backend storage so often. It is very important to have database integrity and rules independent from application (inner or outsource)

但是，如果您有可以在许多不同应用程序中使用的业务逻辑（存储过程）呢？所以取决于：如果您为具有不同后端存储的不同用户制作应用程序，或者您为不经常更改后端存储的用户制作许多应用程序。拥有独立于应用程序（内部或外包）的数据库完整性和规则非常重要