开始构建数据访问层。要考虑的事情？答案

【问题标题】：Starting to construct a data access layer. Things to consider?开始构建数据访问层。要考虑的事情？
【发布时间】：2011-02-15 00:49:12
【问题描述】：

我们的组织使用内联 sql。我们的任务是提供一个合适的数据访问层，并且正在权衡走哪条路的利弊......

数据集
ADO.net
林克
实体框架
亚音速
其他？

我一直在参考的一些教程和文章：

我非常痛苦，很难决定走哪条路。我们的网站是一系列 2 个内部门户网站和一个公共网站。我们使用的是 vs2008 sp1 和框架版本 3.5。

请您就数据访问层的考虑因素以及您面临的任何优缺点给我建议。

PS。我发现亚音速网站的信息有点肤浅，而且似乎很多重点都放在了它和它的开发人员有多“酷”上。我更喜欢他们的演示视频而不是音乐的口头解释？其他人同意吗？

【问题讨论】：

看起来你真的不是在“建造”，而是在寻找一个可以使用的——或者你真的打算从头开始建造一个？（没有错，我自己做过。）
我们在这个主题上非常环保，但确实有开发资源和预算，并且对编码/使用持开放态度。我们要避免的主要事情是先跳脚，所以我们做对了！（我已经编辑了问题以提供更清晰的信息）
见：stackoverflow.com/questions/200279 stackoverflow.com/questions/66156 stackoverflow.com/questions/1055710 stackoverflow.com/questions/2138814 stackoverflow.com/questions/168287 stackoverflow.com/questions/168287 stackoverflow.com/questions/563775 stackoverflow.com/questions/67831 stackoverflow.com/questions/82393 stackoverflow.com/questions/1691575@98765433335
我不同意“Stack Overflow 并不意味着涵盖许多不同问题的重复领域。它旨在拥有一个权威来源”。实际上，它有点混合。如果问题问得好，并且 OP 研究了其他帖子（看起来你有），那么有 good 类似但不完全相同的相关问题是可以的。 底线：我们不是维基百科，没有一篇关于“沥青”的规范、完美的文章——关于“沥青”的原理、属性和用法存在无数问题。这没关系。
@george 社区对重复项的要求比应有的要严格得多。重复是不好的，但是好的相关问题是净正面的，即使有一点重叠。你列出的很多骗子都很糟糕。我需要写博客。

标签： .net sql orm data-access-layer

【解决方案1】：

如果您可以使用 .NET 4.0，我建议您使用 Entity Framework 4。这是一个很好的 ORM，随着时间的推移只会变得更好。您可以使用 Linq 编写查询、插入等，它为您提供了一种与您目前使用的内联 SQL 相当接近的语法。显然，它背后有 MS，因此您可以期待现在和未来都能获得大量信息和熟练的开发人员。

如果您必须继续使用 .NET 3.5，我会考虑 NHibernate。它总体上比 EF4 更成熟，但目前缺乏对 Linq 的全面支持。虽然您将能够使用 Linq 进行相对简单的查询，但对于更复杂的查询，您将不得不使用不太类似于 SQL 的条件 API。我还将使用 Fluent NHibernate 来允许对映射进行代码内配置。它有强大的社区支持，在不久的将来应该会有更好的 Linq 支持。它还具有开源的优势。

这些 ORM 中的任何一个都会负责将系统中的对象映射到数据库。这将使您能够将更多精力集中在构建应用程序逻辑上。因此，我不建议使用 ADO.Net/Datasets。 Linq2Sql 的功能非常好，但永远不会像 Nhibernate 或 EF4 那样强大。 Linq2Sql 总是看起来像是 MS 的第一次尝试，似乎被降级为 Entity Framework。

【讨论】：

【解决方案2】：

数据集 > 对于您获得的东西来说开销太大。这通常被认为是一个在发布之日就已经过时的想法。
ADO.Net（或企业库）> 出于多种原因，我个人偏好。但是，出于许多其他原因（主要是安全性），我们从不使用内联 sql，因此您的里程可能会有所不同。我们走这条路的一个原因是我们的团队对 SQL 非常了解，并且每个生成器要么性能不足，要么你必须知道相当多的 sql 才能调整它们。有了这个选择，我们选择自己做。
Linq > 跳过这个。 LINQ 的新开发基本停止，MS 的资源被转移到实体框架项目。我还发现框架内的线程和其他问题尚未解决。
Entity Framework > 有些人喜欢这样。您仍然需要大量的 SQL 知识才能充分利用它。
亚音速等 > 没有足够的第 3 方经验，无法真正告诉您优缺点。

总而言之，我们更喜欢控制，并且拥有充分利用控制的知识。我们已经尝试过 linq / EF 路线，但并没有给人留下深刻的印象。我见过其他人，并与他们进行了短暂的合作，但除了最基本的 CRUD 类型语句之外，他们在任何事情上都表现不佳。

如果您所做的大部分工作都与 CRUD 相关，那么 EF、Subsonic 或类似的都可以。

评估时需要考虑的一些事项：

它如何处理即席查询？
它如何处理数据分页/排序（SQL 端或将所有内容拉入 Web 服务器）？
什么是内存泄漏？
线程是必需的吗？编写一个简单的应用程序来测试您正在评估的每个应用程序。在不同的内存/cpu 条件下运行它。

祝你好运。

【讨论】：

【解决方案3】：

这不是一个容易的决定。我寻求简单性和灵活性。例如我不太喜欢配置 NHibernate 的 xml 文件；我不喜欢实体框架喷出的大量代码；我担心 linq-to-sql 的生命终结。我不介意从基类（有些人想要纯 POCO 对象）派生来支持映射。我还希望能够在不更改代码的情况下切换数据库，只需更改我的配置即可。其他的小东西也不错，比如：能够将存储过程的结果映射到对象；出于性能原因选择列的子集；如有必要，能够发送纯 sql 语句。

【讨论】：

不需要在 nhibernate 上编写 xml 映射 :-) fluentnhibernate.org
Fluent NHibernate 显着降低了进入 NHibernate 的门槛。然而，它不是一个完整的集合。您可以使用 FNH 进行大部分简单映射，但有些项目没有实现——例如，映射存储过程是一个巨大的问题。

【解决方案4】：

现在所说的问题有点模棱两可。一个“数据层”可以由许多、许多、许多不同的需求和愿望组成。

我假设 SQL Server 是后备数据库。但它是唯一的吗？数据层的同质性如何？

您是否只是在寻找一种简单的方法来查询和获取数据？或者您是否需要完整的对象关系映射解决方案？除了查询之外，您还有其他需求吗？例如迁移和脚手架？

您是否愿意或能够提前牺牲时间来学习更复杂（但灵活）的工具集，例如 NHibernate 或 Subsonic？

在使用 EF、Linq to SQL、Subsonic 和 NHibernate 以不同程度的复杂性工作后，起初没有一个“很难”开始，但找到更复杂问题或边缘情况的解决方案会因每种情况而异。有人可能会说 EF 和 NH 拥有最多的用户，因此很容易找到博客/Stackoverflow 帖子来回答您的问题。在这方面，我对 EF/NH 的运气更好。也就是说，Subsonic 是一个更平易近人的代码库，可以卷起袖子解决自己的问题 (IMO)。

就个人而言，在运行了几次之后，我现在的偏好是总是从我认为最简单的解决方案开始——Linq to SQL。我发现它的进入门槛最低，而且“侵入性”最小。然而，它带有明显的限制（例如对 SQL 服务器的依赖）。但是为了快速而肮脏，只需完成工作，这是我的最爱，因为我不想花费过多的时间来担心我的数据层。只有当需求出现决定转变时，我才会考虑离开——例如最近的项目需要读取/写入 SQLite 和 SQL Server，因此我们选择了 NH。

了解您的实际需求可能有助于形成远离一般评论的答案。

【讨论】：