LINQ to SQL 的优势是什么？答案

【问题标题】：What are the advantages of LINQ to SQL?LINQ to SQL 的优势是什么？
【发布时间】：2009-02-27 07:10:58
【问题描述】：

我刚刚开始在一个中型项目中使用 LINQ to SQL，希望加深对 L2S 提供哪些优势的了解。

我看到的一个缺点是它添加了另一层代码，我的理解是它的性能比使用存储过程和 ADO.Net 慢。似乎调试也可能是一个挑战，尤其是对于更复杂的查询，而且这些最终可能会被移动到存储过程中。

我一直想要一种在更好的开发环境中编写查询的方法，L2S 查询是我一直在寻找的解决方案吗？还是我们刚刚在 SQL 之上创建了另一个层，现在要担心的事情是原来的两倍？

【问题讨论】：

这是一个非常重要的问题，这毫无价值。如果同时列出缺点，列出优点会更有用。这里的所有答案也是 11 岁，所以请用少许盐了解所有这些信息

标签： linq linq-to-sql stored-procedures ado.net

【解决方案1】：

L2S 提供的优势：

没有像 SQL 查询那样的魔法字符串
智能感知
数据库更改时的编译检查
更快的发展
工作单元模式（上下文）
自动生成的域对象是可用的小项目
延迟加载。
学习编写 linq 查询/lambdas 是 .NET 开发人员必须学习的。

关于性能：

在大多数解决方案中，性能很可能不会成为问题。预优化是一种反模式。如果您稍后发现应用程序的某些区域运行缓慢，您可以分析这些部分，在某些情况下甚至可以将一些 linq 查询与存储过程或 ADO.NET 交换。
在许多情况下，延迟加载功能可以提高性能，或者至少可以大大简化代码。

关于调试：

在我看来，调试 Linq2Sql 比存储过程和 ADO.NET 都容易得多。我建议你看一下Linq2Sql Debug Visualizer，它可以让你看到查询，甚至在调试时触发执行以查看结果。
还可以配置上下文将所有sql查询写入控制台窗口，更多信息here

关于另一层：

Linq2Sql 可以看作是另外一层，但它是一个纯粹的数据访问层。存储过程也是另外一层代码，我见过很多部分业务逻辑已经实现到存储过程中的案例。在我看来，这更糟糕，因为您将业务层分成两个地方，开发人员将更难获得业务领域的清晰视图。

【讨论】：

【解决方案2】：

只是一些快速的想法。

一般的LINQ

使用相同的语法和运算符查询内存中的集合和进程外的数据存储
声明式风格非常适合查询 - 在很多情况下都更易于阅读和书写
简洁的语言集成允许编写新的提供程序（进程内外）并利用相同的查询表达式语法

LINQ to SQL（或其他数据库 LINQ）

在需要的地方而不是存储过程中编写查询可以大大加快开发速度：获取所需数据所涉及的步骤要少得多
少得多的字符串（存储过程、参数名称或只是简单的 SQL）涉及的拼写错误可能令人恼火；这枚硬币的另一面是您可以为您的查询获得 Intellisense
除非您打算使用来自 ADO.NET 的“原始”数据，否则无论如何您都会在某个地方拥有一个对象模型。为什么不让 LINQ to SQL 为您处理呢？我更喜欢能够只进行查询并取回对象，准备使用。
我希望性能良好 - 如果性能不佳，您可以自行调整或退回到直接 SQL。使用 ORM 当然不会消除创建正确索引等的需要，您通常应该检查为非平凡查询生成的 SQL。

无论如何它都不是灵丹妙药，但比起直接进行 SQL 查询或使用存储过程，我更喜欢它。

【讨论】：

John 和 Bengt 几乎都说了同样的话，都非常详细！
可能最好在 DB SP 中实现业务逻辑（以便利用 DB 功能进行安全性和性能分析），并且仅使用 LINQ 来减少编码，同时使用从 SP 获取的数据填充对象.
@Faiz：另一方面，在 C# 中实现业务逻辑通常比在 SQL 中实现要简单得多，并且如果您只有单一的数据访问路径（例如数据库前面的分层良好的 Web 服务），那么您可以两全其美。
刚刚看到 SQL Debug Visualizer。看起来如果我们必须在 LINQ 中编写逻辑，我们将必须首先检查 SQL 的外观并将 LINQ 代码修改到相应的 SQL 看起来高效的程度。 IMO 这将杀死您节省的所有时间，而不是编写老式的 ORM 代码..
@Faiz：那么请随意避免它。我会继续喜欢它:)

【解决方案3】：

我必须说它们就是您一直在寻找的东西。习惯它需要一些时间，但一旦你习惯了，你就不会想到回去（至少对我来说）。关于 linq 与存储过程，如果构建错误，性能可能会很差。我转移到 linq to sql 客户端的一些存储过程，这些存储过程编码非常糟糕，因此时间从 20 秒（对于 Web 应用程序完全不可接受）下降到

更新 1： 您还可以获得很大的灵活性，因为您可以限制所获得内容的列，它实际上只会检索它。在存储过程解决方案中，您必须为获得的每个列集定义一个过程，即使基础查询相同。

【讨论】：

【解决方案4】：

作为更新，这里有一些关于 LINQ to SQL 未来的链接：

What is the Future of Linq to SQL

Has Microsoft confirmed their stance on LINQ to SQL end-of-life?

Is LINQ to SQL Dead or Alive?

正如最后一个链接中的评论所述，LINQ to SQL 不会消失，只是至少不会被微软“改进”。这些cmet和帖子随便拿，只是在你的发展计划中要谨慎。

【讨论】：

【解决方案5】：

我们最近通过实体框架环境切换到 LINQ2Entity。之前，我们有基本的 SQLadapter。由于我们使用的数据库相当小，我无法评论 LINQ 的性能。

但我必须承认，编写查询已经变得容易得多，并且添加实体确实可以实现强类型。

【讨论】：

Johannes，我不认为强类型是 linq2entity 与 linq2sql 的论据，因为它也有强类型 :) ...我相信有一些好的，但我仅限于比较 linq2sql 与 ado.net