LINQ无疑简化了数据库编程，但是它有缺点吗？内联SQL要求人们以某种​​方式与数据库进行通信，从而可以打开数据库进行注入。内联SQL还必须经过语法检查，建立计划然后执行，这需要花费宝贵的时间。在出色的数据库应用程序编程中，存储过程也已成为坚如磐石的标准。我认识的许多程序员都使用简化开发的数据层，但是，LINQ并没有达到这一程度。是时候放弃SP并使用LINQ了吗？

解决方案

回答

这是马克西米利安·贝勒(Maximilian Beller)的表演。据他介绍，LINQ要慢得多。
阅读他的综合研究

回答

这取决于我们在做什么。 LINQ在实际数据/集合操作上的效率将不如真实数据库。但是，不必通过网络连接到数据库，我们将节省很多。

如果数据库位于同一台计算机上或者处于正式的"良好连接"状态，则最好使用它。

但是，如果我们要从远程数据库中获取较大的结果集，这可能意味着大量的传输时间，或者如果查询的时间很短，不足以证明开销，那么LINQ可能会更好。

回答

如果我们对基准测试感兴趣，Rico Mariani会进行一项由5部分组成的出色研究，涵盖定性和定量差异。

他可能是一名MS专家，但他以性能方面的坚果而闻名，他的基准测试非常周到且经过深思熟虑。

回答

只需考虑更改列名称，现在即可更改(n)SP和(x)Views。

进行数据库上所有昂贵的工作(例如搜索，排序等)，我们就不会注意到问题。

另外，如果我们想显示一个大的网格而不使用分页...，那么请使用一个速度更快的数据集。

StackOverflow也使用linq2sql吗？

使用ORM是大多数应用程序的处理方式。

PS：另外，关于..等微基准测试，让我们用ORM DO N'T DO IT选择10.000行。这不是为什么要使用ORM。如果要选择10.000行，请使用ADO。

回答

由于LINQ to SQL的结构，它不可能比使用原始SQL(我们自己格式正确的查询或者作为存储过程)更快。 LINQ购买的不是速度而是类型的安全性和组织性。简而言之，ORM通常会为我们带来大部分好处。

LINQ to SQL与速度无关，而是与构建更易于维护的软件系统有关。这是所有软件工程师和架构师关心的事情，例如松耦合和分层

这并不是说我们无法使用LINQ来构建一些真正无法维护的代码-没人阻止我们动手，但是我们-但做得很好，LINQ可以提供巨大帮助。我并不是说LINQ是灵丹妙药。它有很多问题，使得在许多企业环境中都很难使用，这就是MS提供实体框架(ADO.NET 3.0)的原因。当然，考虑到最近的EF不信任投票，即使这样也不是完美的。

LINQ to SQL甚至EF是否比原始SQL更好？我会说一个响亮的地狱呀。还有其他更好的解决方案吗？可能是。

回答

LINQ to SQL实际上在数据库中提出了一些令人震惊的性能问题。基本上，它会根据我们使用的参数的长度来创建多个执行计划。我前不久在我的博客LINQ to SQL上发布了有关它的信息，这可能会导致性能问题。

现在，是说LINQ没有位置吗？几乎不。就像存储过程一样，LINQ在开发工具箱中肯定占有一席之地。最终，我们需要在绝对需要性能的情况下使用存储过程，并在任何其他情况下使用ORM工具。

就内联SQL而言，存在执行内联SQL的方法，因此该计划仅构建一次，并且永远不会重新编译。大多数ORM也应注意性能调优的这一方面，并​​且使用这些方法通常是执行SQL的最安全方法，因为它会迫使我们使用参数化查询。

像大多数数据库解决方案一样，正确的答案取决于我们要解决的问题。如果我们希望开发速度胜于数据库/应用程序性能，那么最好使用LINQ或者其他DAL / ORM工具。如果我们倾向于性能而不是易于开发，那么使用存储过程和纯数据集将是最佳选择。 LLBLGen甚至提供了LINQ to LLBLGen层，因此我们可以使用LINQ来查询LLBLGen的对象，并让LLBLGen实际处理构建查询并避免LINQ的崩溃。

回答

基本前提是有缺陷的。

Inline SQL requires one to communicate with the database in a certain way that opens the database to injections.

不，不是。可以将用户输入的值硬编码到SQL语句中，但是我们也可以使用存储过程来做到这一点。

参数化查询可以防止注入攻击，但是内联SQL可以像存储过程一样容易地进行参数化。

Inline SQL must also be syntax-checked, have a plan built, and then executed.

必须对所有Sql(SP和内联)进行语法检查，并在其首次调用时制定计划。此后，将缓存请求的确切文本和执行计划。如果收到另一个具有完全相同的文本(不包括参数)的请求，则使用缓存的执行计划。

因此，如果将值硬编码为内联SQL，则文本将不匹配，并且必须重新解析查询。但是，如果使用参数，查询的文本将匹配，并且将获得缓存命中。在这种情况下，查询是内联SQL还是SP都没有关系。

换句话说，内联SQL的唯一问题是容易进行缓慢且不安全的操作。但是，使内联SQL快速而安全不再是使用SP的工作。

这使我们进入了LINQ，即使我们将值硬编码到LINQ语句中，也总是使用参数，从而使"快速和安全"内联SQL变得微不足道。

与SP相比，LINQ还具有将所有代码集中在一个位置的优势，而不是分散在两台不同的计算机上。