LINQ to SQL有哪些优点？

Question

我刚开始在一个中型项目上使用LINQ to SQL，并希望增加我对L2S提供的优势的理解。

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

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

Answer 1

L2S提供的优势：

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

关于效果：

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

关于debuging：

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

关于其他图层：

• Linq2Sql可以看作是另一层，但它是一个纯粹的数据访问层。存储过程也是另一层代码，我已经看到很多情况，其中部分业务逻辑已经实现到存储过程中。在我看来，情况要糟糕得多，因为您将业务层拆分为两个位置，开发人员更难以清楚地了解业务领域。

Answer 2

只是一些简单的想法。

LINQ一般

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

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

• 在需要它们而不是存储过程的地方编写查询可以使开发速度更快：获取所需数据所涉及的步骤要少得多
• 在拼写错误可能令人恼火的情况下，涉及的字符串（存储过程，参数名称或纯SQL）的数量要少得多;这个硬币的另一面是你的查询得到智能感知
• 除非你打算使用ADO.NET中的“原始”数据，否则无论如何你都会在某个地方拥有一个对象模型。为什么不让LINQ to SQL为您处理它？我喜欢能够只是做一个查询并找回对象，随时可以使用。
• 我希望性能很好 - 如果不是，你可以自己调整它或者回归直接的SQL。使用ORM当然不会消除创建正确索引等的需要，并且通常应该检查为非平凡查询生成的SQL。

它绝不是灵丹妙药，但我非常喜欢它直接进行SQL查询或使用存储过程。

Answer 3

就像更新一样，这里有一些关于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不会消失，只是至少没有“改进”微软。按照您的意愿阅读这些评论和帖子，只需在您的开发计划中保持谨慎。

Answer 4

我必须说他们是你一直在寻找的。它需要一些时间来适应它，但一旦你这样做，你不能想到回去（至少对我来说）。 关于linq与存储过程，如果构建错误，可能会导致性能不佳。我转移到linq来sql客户端的一些存储过程，这些存储过程被严格编码，因此时间从20秒（对于Web应用程序来说完全无法实现）下降到＆lt; 1秒。而且存储过程解决方案的代码要少得多。

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

Answer 5

我们最近在Entity Framework环境中切换到了LINQ2Entity。以前，我们有基本的SQLadapters。由于我们正在使用的数据库相当小，我无法评论LINQ的性能。

我必须承认，编写查询变得更加容易，添加实体确实可以实现强类型。