sql - Entity Framework VS LINQ to SQL VS ADO.NET 与存储过程？

Question

您如何评价他们中的每一个:

1. 性能
2. 开发速度
3. 简洁、直观、可维护的代码
4. 灵 active
5. 总体

我喜欢我的 SQL，因此一直是 ADO.NET 和存储过程的铁杆粉丝，但我最近尝试了一下 Linq to SQL，并对我编写数据访问层的速度感到震惊，并且决定花一些时间真正了解 Linq to SQL 或 EF...还是两者都不了解？

我只是想检查一下，这些技术中是否存在会导致我的研究时间毫无用处的重大缺陷。例如。性能很糟糕，对于简单的应用程序来说很酷，但只能带你到目前为止。

更新: 您能否专注于 EF VS L2S VS SP 而不是 ORM VS SP？我主要对 EF VS L2S 感兴趣。但我也很想将它们与存储过程进行比较，因为我对普通 SQl 非常了解。

Answer 1

首先，如果您要开始一个新项目，请使用 Entity Framework (“EF”) - 它现在生成更好的 SQL(更像 Linq to SQL 所做的)，并且比 Linq to 更易于维护且更强大SQL(“L2S”)。自 .NET 4.0 发布以来，我认为 Linq to SQL 是一种过时的技术。 MS 对于不再继续进一步开发 L2S 持非常开放的态度。

1) 性能

这个问题很难回答。对于大多数单实体操作 ( CRUD )，您会发现所有三种技术的性能几乎相同。您必须了解 EF 和 Linq to SQL 的工作原理才能充分利用它们。对于轮询查询等大容量操作，您可能希望让 EF/L2S“编译”您的实体查询，以便框架不必不断重新生成 SQL，否则您可能会遇到可扩展性问题。 (参见编辑)

对于要更新大量数据的批量更新，原始 SQL 或存储过程始终比 ORM 解决方案执行得更好，因为您不必通过网络将数据编码到 ORM 来执行更新。

2) 开发速度

在大多数情况下，EF 在开发速度方面将击败裸 SQL/存储过程。 EF 设计器可以在数据库发生变化时(根据请求)更新模型，这样您就不会遇到对象代码和数据库代码之间的同步问题。我唯一不会考虑使用 ORM 的情况是，当您正在执行不进行任何更新的报告/仪表板类型应用程序时，或者当您创建一个应用程序只是为了对数据库执行原始数据维护操作时。

3)整洁/可维护的代码

毫无疑问，EF 击败了 SQL/sprocs。由于您的关系是建模的，因此代码中的联接相对较少。对于大多数查询，实体的关系对于读者来说几乎是不言而喻的。没有什么比必须逐层调试或通过多个 SQL/中间层才能了解数据实际发生的情况更糟糕的了。 EF 以非常强大的方式将数据模型带入代码中。

4) 灵 active

存储过程和原始 SQL 更加“灵活”。您可以利用存储过程和 SQL 为奇怪的特定情况生成更快的查询，并且您可以比使用 ORM 更轻松地利用 native 数据库功能。

5) 总体

不要陷入选择 ORM 与使用存储过程的错误二分法。您可以在同一个应用程序中使用这两种方法，而且您可能应该这样做。大批量操作应该放在存储过程或 SQL(实际上可以由 EF 调用)中，并且 EF 应该用于您的 CRUD 操作和大多数中间层的需求。也许您会选择使用 SQL 来编写报告。我想这个故事的寓意和以往一样。使用适合工作的正确工具。但最重要的是，EF 如今非常好(从 .NET 4.0 开始)。花一些时间实时阅读并深入理解它，您可以轻松创建一些令人惊叹的高性能应用程序。

编辑:EF 5 使用 auto-compiled LINQ Queries 稍微简化了这部分。 ，但对于真正的大批量内容，您肯定需要测试和分析现实世界中最适合您的内容。