实体框架VS LINQ到SQL VS ADO。NET存储过程?

在以下方面，你如何评价它们:

  1. 性能
  2. 发展速度
  3. 整洁、直观、可维护的代码
  4. 灵活性
  5. 整体

我喜欢我的SQL，所以一直是ADO的铁杆粉丝。NET和存储过程，但我最近玩了一个Linq to SQL，并被我写出我的DataAccess层的速度所震惊，并决定花一些时间真正理解Linq to SQL或EF…或不?

我只是想确认一下，这些技术中没有什么重大缺陷会让我的研究变得毫无用处。例如，性能很糟糕，对于简单的应用程序来说很酷，但只能到此为止。

< >强更新: 你能专注于EF VS L2S VS SPs而不是ORM VS SPs吗?我主要对EF VS L2S感兴趣。但我也热衷于将它们与存储的procs进行比较，因为纯SQl是我很了解的东西

185575 次浏览
小开

LINQ-to-SQL是一项出色的技术，使用起来非常简单，并且大体上可以生成非常好的后端查询。LINQ-to-EF本来打算取代它，但从历史上看，它的使用非常笨拙，生成的SQL也差得多。我不知道目前的情况，但是微软承诺将L2S的所有优点迁移到L2EF中，所以现在可能一切都好了。

就我个人而言，我非常不喜欢ORM工具(详见我的diatribe 在这里)，所以我认为没有理由支持L2EF，因为L2S给了我所有我期望从数据访问层需要的东西。事实上，我甚至认为L2S特性(如手工制作的映射和继承建模)增加了完全不必要的复杂性。但那只是我。: -)

小开

存储过程:

(+)

  • 极大的灵活性
  • 完全控制SQL
  • 最高的可用性能

(-)

  • 需要SQL知识
  • 存储过程不在源代码控制范围内
  • 在指定相同的表和字段名时，大量的“重复自己”。在重命名一个DB实体并丢失对它的某些引用后，很可能会破坏应用程序。
  • 缓慢的发展

ORM:

(+)

  • 快速发展
  • 数据访问代码现在在源代码控制下
  • 您与DB中的更改隔离开来。如果发生这种情况，您只需要在一个地方更新您的模型/映射。

(-)

  • 业绩可能会更差
  • 没有或很少控制ORM生成的SQL(可能效率很低或bug更多)。可能需要进行干预并将其替换为自定义存储过程。这将使你的代码变得混乱(一些LINQ在代码中，一些SQL在代码中和/或在源代码控制之外的DB中)。
  • 因为任何抽象都可能产生“高级”开发人员，他们根本不知道它是如何工作的

一般的权衡是在拥有很大的灵活性和损失大量时间与受到限制，但可以很快完成之间进行。

这个问题没有统一的答案。这是神圣的战争。这也取决于手头的项目和你的需求。选择最适合你的。

小开

你的问题基本上是O/RM vs手写SQL

使用ORM还是普通SQL?< / >

看看其他的O/RM解决方案，L2S并不是唯一的一个(NHibernate, ActiveRecord)

http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software

针对具体问题:

  1. L2S非常擅长生成SQL，这取决于O/RM解决方案的质量
  2. 一旦了解了流程，使用O/RM通常会快得多
  3. 代码通常也更整洁，更易于维护
  4. 直接SQL当然会为您提供更大的灵活性，但大多数O/RM可以执行除最复杂的查询以外的所有查询
  5. 总的来说，我建议采用O/RM，灵活性损失可以忽略不计
小开
最佳答案

首先，如果你正在开始一个新项目，使用实体框架(“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/stored procs。EF设计器可以在数据库发生变化时(根据请求)从数据库更新模型，因此您不会遇到目标代码和数据库代码之间的同步问题。我唯一不考虑使用ORM的情况是，当您在做一个报告/仪表板类型的应用程序时，您不做任何更新，或者当您创建一个应用程序只是为了对数据库进行原始数据维护操作时。

3)整洁/可维护的代码

EF击败了SQL/sprocs。因为对关系进行了建模，所以代码中的连接相对较少。对于大多数查询，实体之间的关系对读者来说几乎是不言而喻的。没有什么比不得不从一层调试到另一层或通过多个SQL/中间层来了解数据实际发生了什么更糟糕的了。EF以一种非常强大的方式将数据模型引入到代码中。

4)灵活性

存储的proc和原始SQL更“灵活”。您可以利用spprocs和SQL为特定情况生成更快的查询，并且您可以比使用和ORM更容易地利用本机DB功能。

5)整体

你可以在同一个应用程序中使用这两者，你可能应该这样做。大批量操作应该放在存储过程或SQL(实际上可以由EF调用)中，EF应该用于CRUD操作和中间层的大部分需求。也许您会选择使用SQL来编写报告。我想这个故事的寓意一直都是一样的。使用正确的工具。但是最重要的是，EF现在非常好(到。net 4.0为止)。花点时间深入阅读和理解它，你就可以轻松地创建一些令人惊叹的高性能应用程序。

编辑: EF 5用自动编译的LINQ查询简化了这一部分，但是对于真正的大容量的东西，你肯定需要测试和分析在现实世界中最适合你的东西。

小开

如果您追求的是存储过程的功能和性能，以及Entity Framework等工具提供的快速开发，那么您可能需要考虑一种全新的方法。

我已经在一个小项目上进行了SQL+的测试，它真的很特别。基本上，您可以向SQL例程添加相当于注释的内容，这些注释向代码生成器提供指令，然后代码生成器根据实际的SQL例程构建一个非常好的面向对象类库。有点像反向的实体框架。

输入参数成为输入对象的一部分，输出参数和结果集成为输出对象的一部分，服务组件提供方法调用。

如果您希望使用存储过程，但仍然希望快速开发，那么您可能需要看看这些东西。


提交答案