数据集或实体数据模型

当涉及到向数据库存储数据和从数据库检索数据时，您有几个选项可供选择：

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

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

如果你想真正了解EF CF，我强烈推荐Julia Lerman的书《EF CF》——这是一本简短、写得很好、非常有用的指南，你只需要一两天的时间就可以完成的主要部分。

希望这能有所帮助。

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

毫无疑问，对于企业级应用程序或网站，您希望调查ADO.NET或ORM，但这无助于回答这个问题，这个问题与在向导中选择"数据集"answers"实体数据模型"之间的区别有关。

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

EF会让你很快起床并跑步，但根据我（非常有限）的经验，维持它是一种痛苦。

是什么决定了这是你仅有的两个选择？您可以使用更多的ORM。

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

仅使用数据集（数据表）来检索和读取数据。任何需要保存到数据库的数据都应该在数据库中直接操作。。。在数据集中做这件事，然后保存它是没有意义的。在多用户环境中，用户单击"保存"后立即将更改保存到数据库几乎总是更好的。

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

让我们举一个简单的例子，说明您在哪里保存联系人（姓名、电话、电子邮件、地址等），然后检索今天添加的联系人列表。。。我建议你这样做：

1） 添加联系人-客户端（web或其他）收集数据-->数据保存在contact业务对象中-->验证contact对象-->调用存储库层以保存contact对象（添加存储库层很有用，但对于保持客户端的数据层抽象性来说不是必需的）-->存储库调用数据层以保存联系人对象（在这里，可以使用Command对象进行简单的ADO.NET调用，以调用存储过程，将联系人保存在数据库中）。此用例中未使用任何数据集。

2） 检索联系人列表--客户端调用存储库层以获取联系人列表-->存储库层调用数据层以检索数据-->此处将数据列表作为数据集（datatable）进行检索-->将数据表返回给客户端，并让客户端在呈现数据时直接从datatable读取数据。即使是一个联系人也可以作为数据集检索。

p.S：ORM几乎总是一种过度的做法。它几乎总是被使用，因为某些开发人员喜欢保持一切面向对象。。。因此添加了一个额外的层，即使它没有任何用处（IMHO）。

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