Linq to SQL 有什么问题？答案

【问题标题】：What's wrong with Linq to SQL?Linq to SQL 有什么问题？
【发布时间】：2008-10-02 23:48:48
【问题描述】：

Linq to SQL 出了什么问题？

或者 - Linq to SQL 会使其不适用于新项目或现有项目？我想了解您为什么不为特定项目选择 Linq to SQL - 包括哪些项目参数使其不适合。

【问题讨论】：

标签： .net database linq-to-sql

【解决方案1】：

它不太适应数据库模式的变化。您必须重建 dbml 层并重新生成数据上下文。

与任何 ORM 一样（我不参与关于它是否是 ORM 的争论），您必须知道正在生成什么 SQL，以及这将如何影响您的调用。

插入不是批处理的，因此性能成本可能很高。

它正在被实体框架淘汰

尽管它使用的提供程序模型允许为其他 DBMS 平台构建提供程序，但仅支持 SQL Server。

[编辑 @ AugustLights - 以我的经验：] 延迟加载可能需要一些黑客才能开始工作。

话虽如此，我认为如果使用得当，它会很方便

【讨论】：

如果您不使用设计器或代码生成器怎么办？映射可以通过属性或 XML 配置完成 - 在这种情况下，使用 Linq to SQL 响应模式的变化将类似于其他 ORM，不是吗？
相信我，Erik，您不想手动进行映射。您需要设置的属性太多了。哦，还有一件事 LINQ to SQL 设计器非常有问题。
非常正确，但典型的 LINQ to SQL 用户通常不会围绕 XML 进行黑客攻击，但这是真的，LINQ 2 SQL 和 EF 的局限性都在于设计者体验跨度>
延迟加载需要破解？ DataLoadOption 类非常方便，并且 DeferredLoadingEnabled = false 对我来说似乎不是什么大问题？
> 您需要设置的属性太多了。

【解决方案2】：

对于需要使用 SQL Server 以外的数据库的项目：

1) 你被锁定在使用 SQL Server

对于具有复杂实体关系和/或关系随时间逐渐变化的项目：

2) 您被锁定在表到类的一对一映射中

对于必须使用 .NET 1.x 版本的项目

3) 不适用于 .NET 1.x

【讨论】：

【解决方案3】：

无法在数据上下文中混合使用延迟加载/急切加载。
真正的持久性无知是非常困难的。
映射选项有限。例如，不存在多对多关系。
将映射与架构更改重新同步很痛苦。

尽管有以上所有，我认为 linq-to-sql 是许多项目的绝佳选择。

【讨论】：

【解决方案4】：

由于System.Data.Linq.DataContext 类上缺少接口，因此在单元测试时很难模拟。这是一种可能的方法：Mocking LINQ to SQL DataContext。

【讨论】：

啊，但是，没有可用于存储过程的模拟。
我只是花了一天时间尝试以各种颇具想象力的方式模拟 Table，然后厌恶地放弃了。啊！

【解决方案5】：

因为你没有使用 3.5...这是一个有效的答案吗？！？！？

【讨论】：

有效，但没那么有趣。

【解决方案6】：

嗯，我已经使用 LINQ to SQL 开发了一些应用程序。我发现的主要问题之一是必须对您的应用程序进行分层。在 LINQ to SQL 中，实体类与数据访问代码密切相关。此外，DataContext 存在一些问题，这意味着您可以使用 DataContext 对象来检索项目，但不能将项目（对象）转移到另一个 DataContext（至少不容易）。

如果您不关心正确分层应用程序，并且如果您只想快速创建应用程序（也称为快速应用程序开发），LINQ to SQL 将非常有用。

【讨论】：

它不具备将对象从一个 DC 转移到另一个内置所需的一切。但是，可以轻松添加 - 请参阅本文末尾的“LinqSync”类：blog.huagati.com/res/index.php/2008/06/23/…
我关心“正确分层我的应用程序”，我仍然喜欢 linq-to-sql。

【解决方案7】：

LINQ-to-SQL 的许多优势来自据称能够在您的代码隐藏中基于来自您的 dbml 的强类型可查询/可枚举数据对象构建数据查询（它扮演着非常重要的角色）有限的 DAL）。因此，正如已经提到的那样，结果是它在一定程度上鼓励您在应用程序中使用严格定义和分离的层或层。
为了反驳这一点，这应该意味着您应该能够消除您写入数据库存储过程中的大部分或全部任何业务逻辑，因此至少您只需转到处理数据的代码即可更改不影响模式的业务规则...但是，当您意识到使用带有分组的聚合的外部联接编写查询是多么复杂时，至少在您第一次接近它时，这会有点崩溃。所以你会很想在你知道的 SQL 中编写存储过程，它是如此简单且擅长做这些事情，而不是花额外的时间试图找出 LINQ 语法来做同样的事情，而它只是要转换它反正丑陋的 SQL 代码...
话虽如此，我真的很喜欢 LINQ，当我开始忽略这种“查询语法更容易阅读”的情绪并转向方法语法时，我对它的尊重大大增加了。从未回头。

【讨论】：

【解决方案8】：

如果您想使用除 SQL Server 之外的其他 RDBMS，我将其标记为技术“搅局者”的唯一情况。（虽然它可以解决 - 请参阅 Matt Warren 的博客 @http://blogs.msdn.com/mattwar/）

除此之外，您的问题的先前答案中已经列出了一些优点和缺点。但是，到目前为止提到的所有负面因素都有解决方法，因此它们并不是真正的阻碍。

一个非技术性的 [潜在] 阻碍是 MSFT 将放弃它转而支持 EF 的风险...更多信息请点击此处：http://oakleafblog.blogspot.com/2008/05/is-adonet-team-abandoning-linq-to-sql.html

尽管（在我看来，）EF 的当前状态足以让他们继续在 L2S 上工作。所以让我们希望他们这样做......

【讨论】：

【解决方案9】：

真正的 ORM 应该将业务实体的设计与持久性介质分开。这样，您可以分别重构其中任何一个，并且只需要维护两者之间的映射。这减少了您需要为数据库更改维护的应用程序逻辑代码量。

要使用 Linq-to-SQL 完成这种与持久性无关的方法，您必须在 DTO 处使用其生成的类，并维护 DTO 和实体之间的映射逻辑。

有更好的 ORM 可以采用这种方法（如 NHibernate），可以大大减少对 DTO 的需求。

【讨论】：

【解决方案10】：

它doesn't appear to have 对 DB 列上的默认值的任何支持。

【讨论】：

【解决方案11】：

这个问题在over here 之前被问过一次。但是，实质上，LINQ to SQL 会在您的数据库中生成次优执行计划。对于您搜索的每个不同长度的参数，它将强制创建不同的执行计划。这最终会堵塞数据库中用于缓存执行计划的内存，并且您将开始使旧查询过期，当它们再次出现时需要重新编译。

正如我在链接到的问题中提到的，这取决于您要完成什么。如果您愿意以执行速度换取开发速度，LINQ to SQL 可能是一个不错的选择。如果您担心执行速度，还有其他可用的 ORM/DAL/解决方案，它们可能需要更长的时间才能使用，但会为您提供针对架构更改的未来证明和性能更好的解决方案，但代价是额外的开发开销。

【讨论】：

我对这个答案持怀疑态度。你的来源是什么，或者有什么方法可以证明这个结论是正确的？
RTM 之前的情况（即测试版）曾经是这种情况。不再是这种情况了，因为它在 RTM 之前就已修复。
源代码可以在这里找到：connect.microsoft.com/VisualStudio/feedback/…
似乎堆栈溢出处理正常。
我相信 RTM 版本的性能是足够的（假设查询被正确编写）。比实体框架的实现更好。