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

Question

关于使用LINQ执行内联查询和操作的一般共识是什么？如何将SQL语句嵌入到代码中(这被认为是否)？

Answer 1

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

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

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

Answer 2

你是对的:"在你的代码中嵌入SQL语句也不错." 这很糟糕.

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

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

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

当然,如果生成的Linq to SQL变得混乱和缓慢,你必须使用proc.

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