DAL 层：EF 4.0 或带有存储过程的普通数据访问层

Posted 2023-02-24

【中文标题】DAL 层：EF 4.0 或带有存储过程的普通数据访问层

【英文标题】：DAL Layer : EF 4.0 or Normal Data access layer with Stored Procedure

【发布时间】：2011-02-22 20:52:37

【问题描述】：

应用：

我正在开发一个将用作产品的中大型应用程序，我们需要决定我们的 DAL 层。应用程序 UI 位于 Silverlight 中，而 DAL 层将位于服务层之后。我们也在推进领域模型，所以我们的数据库表和领域类没有相同的结构。所以像 Data Mapper 和 Repository 这样的模式肯定会出现。

我需要优先考虑以下因素来设计 DAL 层

开发速度高于平均水平 维护 技术的未来支持和稳定性 性能

限制：

1) 由于我们需要严格使用微软，我们不能使用 NHibernate 或除 EF 4.0 之外的任何其他 ORM

2) 我们可以使用任何代码生成工具（应该是开源的或非常便宜的），但它只能在 .Net 中生成代码，因此不会有任何许可问题。

问题

我阅读了很多关于 EF 4.0 的文章，一开始看起来它仍然缺少 NHibernate 的功能，但它比 EF 1.0 好很多

那么，你们觉得我们应该继续使用 EF 4.0 还是我们应该坚持使用 ADO .Net 并使用任何代码生成工具，如 code smith 或任何其他你觉得最好的工具

此外，我还需要回答一些问题，例如，如果将来我们在某些功能上坚持使用 EF 4.0 或遇到严重的性能问题，将应用程序从 EF 4.0 移植到 ADO .Net 需要多长时间。

在相反的情况下，如果我们继续选择 ADO .Net，那么切换到 EF 4.0 需要多长时间

最后..当我阅读这篇文章时，我发现仅代码方法（使用 POCO 类）似乎最适合我们的要求，因为从一种技术切换到另一种技术真的很容易。

请分享您的想法，并请指导上述问题

【问题讨论】：

EF 4 with OData 无疑是最好的！

【参考方案1】：

使用 EF4 将为您节省大量手动编码 - 或代码生成。仅凭这一点似乎就证明了使用它的合理性 - 最好的代码和唯一保证没有错误的代码是您不需要编写的代码。

EF4 和 NHibernate 等是非常强大的工具，可以处理最苛刻和最复杂的业务需求——比如数据库表中的继承等等。但是，它们确实会增加一些开销 - 而且它们并不总是易于学习和掌握。

所以我的挑衅性问题是：为什么不使用 Linq-to-SQL？如果您只需要 SQL Server 作为后端，并且您的映射几乎始终是域模型中表和类之间的 1:1 映射，那么这可能比使用 EF4 或 NHibernate 容易得多。

Linq-to-SQL 绝对比 EF4 更简单、更快捷 - 它只是数据库顶部的一个相当薄的层。这比学习 NHibernate 容易得多 - 无需学习凌乱的映射语法，您可以通过视觉设计师获得支持。它非常简单，您甚至可以进入其中并使用例如操作代码生成。 T4 模板（参见 Damien Guard 的 Linq-to-SQL templates）。

即使在 .NET 4 / VS 2010 中也 100% 支持 Linq-to-SQL，因此它很有可能在 VS2012 中仍然存在（或者下一个将被称为）。所以所有那些关于它消亡的世界末日预言都在很大程度上被夸大了——我不会担心它的未来证明。

更新： Linq-to-SQL 和 EF 之间的一些性能比较：

Entity Framework and Linq-to-SQL Performance Comparison Looking at EF Performance - some surprises Entity Framework and LINQ to SQL

一般来说，Linq-to-SQL 似乎在查询性能上有优势，但 EF 似乎在更新方面做得更好。

【讨论】：

为什么说 LINQ-to-SQL 比 EF 4 快？

@Meysam Javadi：Linq-to-SQL 是从数据库表到 .NET 类的相当薄的 1:1 映射； EF4 是一个更加精细的系统，具有三层映射：存储模型、.NET 类域中的概念模型以及它们之间的映射层。这使得它变得更慢 - 更多开销、更多映射、从数据库表获取数据到 .NET 对象所需的更多工作。

其实我们的数据库模型和概念模型是不一样的，我们想要复杂类型和继承支持，据我所知是EF支持而不是L2S

【参考方案2】：

您从哪里得知绑定存储过程的 DAL 是正常的？我个人像 15 年前一样向他们告别，然后转向市场上任何 ORM 之类的系统（兴：与 nhibernate 之类的东西相比，实体框架相当糟糕）。我个人总是非常高兴，除了 MS“粉丝”之外的每个人 ORM 都是新事物。

即使考虑到 Entity Framework 的限制 - 它也比您可以手动提出的存储过程要好得多。

1：通常大约 40% 到 60% 的代码处理数据库交互。任何非愚蠢的 ORM 都可以消除这种情况 -> 进行数学运算。

2：见 1。

3：好问题。遗憾的是，MS 在数据访问领域有做过非常愚蠢的事情的历史。

4：很可能与您手写的相同 - 5% 以内。遗憾的是，您的 ORM（实体框架）没有实现任何真正有趣的功能（缓存等），因此不会自动获得巨大的收益。

【讨论】：

使用代码生成工具和 ORM 可能会加快编码速度，但与存储过程相比，它们在性能比较中失败了。

特别是当现实进入时，您会发现存储过程的性能优势已被现代 ndatabase develoeprs...hm... 或 sql serverin 版本 7.0 (!) 与查询计划缓存用于动态sql.