如果使用内联SQL是不好的，那么在实践中使用LINQ执行查询有何不同？

Question

使用LINQ执行内联查询和操作的一般共识是什么？将SQL语句嵌入到代码中有何不同（这被认为是否）？

Answer 1

忽略LINQ的所有非SQL相关用法，只考虑LINQ-to-SQL。

LINQ查询是保留查询定义的对象，等效SQL仅在实际迭代查询时实例化。这允许组件被正确分离并允许管道样式处理，其中查询由较低层（例如，通过存储库）返回并且由堆栈上的较高组件转换。查询可以容纳来自处理管道中每个组件的新过滤器，连接和其他“工件”，直到它到达最终迭代的最终形式。在实践中使用直接文本SQL这种操作是不可能的。

LINQ的另一个优点是它的语法更易于理解非数据库开发人员。 SQL语法专业知识是一项令人惊讶的难以找到的资产。很少有开发人员愿意花时间学习SELECT * FROM ... WHERE ...以外的SQL的微妙点。 linq语法更接近.Net日常环境并利用该层的现有技能集（例如lambda表达式），而不是强迫开发人员学习目标后端的正确SQL（T-SQL，PL-SQL）等等）。鉴于linq表达式在关系代数中非常直接地表达了期望的结果，提供者可以更容易地生成适当的SQL（甚至直接生成执行计划！）。将此与不可能的任务'通用'进行比较，数据库驱动程序必须与SQL文本一起使用。还记得ODBC转义语法吗？

Answer 2

你是对的：“在你的代码中嵌入SQL语句也不错。”太可怕了。

这样做会使您的应用程序高度耦合，脆弱且难以维护。至少，如果你在procs中拥有它，当你改变某些东西时，你可以搜索依赖性。

存储过程，我觉得真的需要消除处理业务逻辑的那些过程。

原因是业务逻辑属于业务层 - 而不是数据层。

当然，如果生成的Linq to SQL发现了凌乱的东西。慢，你必须使用proc。

Linq To SQL的一大优势是您可以将过滤器链接在一起 - 您可以根据需要通过逻辑动态添加子句。您不需要仅仅因为要根据多个参数调用一组数据而创建新的过程。

Answer 3

在代码中嵌入SQL语句也不错。这完全取决于您编写应用程序的哪一层。

任何与读取和写入数据存储相关的内容都应该在数据访问层上。

Answer 4

“Linq To Sql”的两个优点 与（常见的最坏情况）“内联SQL”。

将参数视为参数，而不仅仅是连接文本 - 这可以克服SQL注入问题。

单独的模型层允许编译时检查生成的sql是否与模式匹配。 （在内联sql的最坏情况下，如果引用已删除的列，则无法在编译时知道，例如）

Answer 5

一方面，LINQ语句是参数化的 - 内联查询不一定如此。另一方面，LINQ基本上创建了一个ORM层 - 允许数据库对象基本上被视为代码中的对象 - 提供编译时检查。另一方面，内联查询是一小段文本，在编译时不会中断...

Answer 6

看看其他答案，也许我误解了这个问题......但我在谈论C＃中的正常LINQ集合，而不是LINQ-to-SQL：

当你在代码中嵌入 SQL 语句时（而不是使它们成为变量或以其他方式参数化你的SQL），如果你想支持不同的数据库，你就会让自己变得更加困难在将来。与SQL一样古老和标准化，供应商之间仍然存在许多不兼容性。

使用LINQ，可移植性不再是问题 - 您的代码是用C＃编写的，而LINQ 是 C＃。

Answer 7

从我的小小理解，无论你使用LINQ-to-SQL还是任何其他ORM或你自己的包装SQL调用的代码，它基本上都给你一个抽象，你不必担心SQL。

另外，如果我是正确的 - LINQ to SQL仅支持SQL Server 我认为，它允许您使用LINQ语法以类似SQL的方式构建条件。

就个人而言，我不知道为什么有人会使用LINQ to SQL 专家可以帮我理解它的需要吗？

Answer 8

在某些代码行中，有人会在某个时候决定是否适合键入SQL。但是，不要这样做，你将使用LINQ。

因此，当SQL不应该内联LINQ时，这不是问题。问题是您希望数据存储访问表示的位置。如果您在某些代码行编写LINQ，并且您觉得这个范围无法访问存储的数据，那么它就是错误的地方。

LINQ只是用于数据操作的抽象。这是过滤集的快捷方式。就像数据库理解SQL一样，.NET环境也有一种与数据交互的语言。

LINQ和循环中的if语句，来自文件或网络套接字的数据有什么区别？没有，这只是语法。如果您SELECT * FROM table，针对函数过滤每一行，与使用LINQ执行where c.SomeProperty < x有什么不同？只是语法。

当然，LINQ知道并做的不仅仅是从数据库中返回行。它允许您从集合中实例化对象，但SQL语句结果中的= new ClassName(column1, colum2)也是如此。

简而言之，如果在代码中编写内联SQL的地方是禁止的，那么应该编写LINQ。

但这因项目而异。数据库主要理解SQL，因此至少在代码，库或环境中的某处有内联SQL。

Answer 9

广泛使用嵌入式SQL，真正的危险在于它是一种代码生成技术。你编写C代码（或任何语言），然后切换到SQL，然后再回到C。在编译之前，预处理器将代码重写为全部C.结果可能会生成非常混乱的错误消息。你被迫学习API来与数据库进行交互，嵌入式SQL应该让你免于这个数据库。最后，您可能会将业务规则嵌入到查询中，从而混淆业务层和数据层。 Linq避免了其中的一些问题。首先，Linq是该语言的一部分。这些结构或多或少都像程序员所期望的那样工作。涉及一些SQL类型语法，但大多数语法都集中在宿主语言（即C＃）上。编译检查是在您编写的实际代码上完成的。因此，在预处理之前不需要将错误转换为语法。查询的结果是对象和集合，就像您期望的那样。但是，仍然存在在数据层中混合业务逻辑的危险。此外，Linq还有自己的错误消息问题，其中通常不包括相关字段。它仍然是对象世界和关系世界之间的妥协。