Linq to SQL有什么问题？
或者说，Linq to SQL有什么缺点使其不适合某个项目，无论是新项目还是现有项目？我想了解为什么您会选择不在特定项目中使用Linq to SQL - 包括哪些项目参数使其不适用。
11个回答
16
它对数据库架构的变化不太适应。您需要重建dbml层并重新生成数据上下文。
像任何ORM一样（我不会涉及它是否是ORM），您必须要知道生成了什么SQL，并且如何影响您的调用。
插入操作没有批处理，因此性能成本可能会很高。
它正在被放弃，转而使用Entity Framework
尽管它使用了提供程序模型，允许为其他DBMS平台构建提供程序，但只支持SQL Server。
[编辑@ AugustLights - 根据我的经验：] 懒加载可能需要一些修改才能正常工作。
话虽如此，如果使用正确，我认为它非常方便。
- lagerdalek
9
4如果你不使用设计师或代码生成器，那怎么办？可以通过属性或XML配置进行映射-如果架构发生变化，则使用Linq to SQL响应类似于其他ORM的方式，对吧？ - Erik Forbes
1相信我，Erik，你不想手动进行映射。你需要设置的属性太多了。哦，还有一件事，LINQ to SQL 设计器非常有 bug。 - azamsharp
@Longhorn213，你是如何分层你的应用程序的？你只是将LINQ到SQL代码放在UI事件中吗？ - azamsharp
关于数据库模式更改 - 尽管设计师不支持同步更改，但有第三方工具可以处理。其中之一是我的插件 - Huagati DBML 工具。如果您想尝试，请从 http://www.huagati.com/dbmltools/ 下载试用版。 - KristoferA
2根本不是这样。只需在需要的每个具有IsPrimaryKey = true的属性上放置[Column]，并添加一些[Association]，就可以让你走得更远。 - Lucas
显示剩余4条评论
9
对于需要使用除SQL Server之外的数据库的项目：
1）您被限制使用SQL Server
对于具有复杂实体关系和/或随时间逐渐变化的关系的项目：
2）您被限制将表与类进行一对一映射
对于必须使用.NET 1.x版本的项目：
3）不能在.NET 1.x上运行
1）您被限制使用SQL Server
对于具有复杂实体关系和/或随时间逐渐变化的关系的项目：
2）您被限制将表与类进行一对一映射
对于必须使用.NET 1.x版本的项目：
3）不能在.NET 1.x上运行
- hurst
4
- 在数据上下文中没有混合使用延迟加载/急切加载的方法。
- 真正的持久性不可知性非常困难。
- 映射选项有限。例如，没有多对多关系。
- 重新同步映射以适应模式更改是痛苦的。
尽管以上所有问题，我认为linq-to-sql对于许多项目来说是一个很好的选择。
- liammclennan
3
由于 System.Data.Linq.DataContext 类缺乏接口，因此在单元测试中进行模拟很困难。以下是一种可能的方法：模拟 LINQ to SQL DataContext。
- jalbert
2
啊，但是存储过程没有可用的模拟。 - Graviton
我刚刚花了一整天尝试以各种相当富有想象力的方式模拟Table<T>，最终感到非常沮丧。呃！ - Peter Mounce
3
因为您没有使用3.5版本...那算是一个有效的回答吗？！？！
- RhysC
1
2有效，但不是很有趣。 - user1228
1
嗯，我使用LINQ to SQL开发了一些应用程序。我发现的主要问题之一是必须分层应用程序。在LINQ to SQL中，实体类与数据访问代码紧密耦合。此外，DataContext存在一些问题，这意味着您可以使用DataContext对象检索项目，但不能轻松地将项目（对象）转移到另一个DataContext。
如果您不关心正确分层应用程序，并且只想快速创建应用程序（也称为RAPID应用程序开发），那么LINQ to SQL将非常有用。
- azamsharp
2
它并不包含从一个DC传输对象所需的所有内容。但是，这可以很容易地添加 - 请参见本文末尾的“LinqSync”类：http://blog.huagati.com/res/index.php/2008/06/23/application-architecture-part-2-data-access-layer-dynamic-linq/ - KristoferA
我关心“适当分层我的应用程序”，我仍然喜欢linq-to-sql。 - liammclennan
1
LINQ-to-SQL的许多优点都来自于它可以根据强类型查询/可枚举数据对象在代码后台中构建数据查询。这些数据对象来自于dbml（扮演非常有限的DAL角色）。因此，正如已经提到的那样，它会在一定程度上鼓励您在应用程序的强定义和分离层或层次之外进行操作。
为了反驳这一点，这意味着您应该能够消除大部分或所有写入数据库存储过程的业务逻辑，因此，至少您只需要去处理与数据相关的代码以更改非模式影响的业务规则...然而，当您意识到编写具有聚合和分组的外连接查询有多么复杂时，情况就有点不同了，至少在您第一次尝试时是这样。因此，您会被诱惑使用您熟悉的简单SQL编写sprocs，而不是花费额外的时间尝试弄清楚LINQ语法，即使它最终会将其转换为丑陋的SQL代码...
话虽如此，我真的很喜欢LINQ，当我开始忽略我看到的“查询语法更易于阅读”的观点并切换到方法语法时，我对它的评价大大提高了。从那时起，我再也没有回头过。
为了反驳这一点，这意味着您应该能够消除大部分或所有写入数据库存储过程的业务逻辑，因此，至少您只需要去处理与数据相关的代码以更改非模式影响的业务规则...然而，当您意识到编写具有聚合和分组的外连接查询有多么复杂时，情况就有点不同了，至少在您第一次尝试时是这样。因此，您会被诱惑使用您熟悉的简单SQL编写sprocs，而不是花费额外的时间尝试弄清楚LINQ语法，即使它最终会将其转换为丑陋的SQL代码...
话虽如此，我真的很喜欢LINQ，当我开始忽略我看到的“查询语法更易于阅读”的观点并切换到方法语法时，我对它的评价大大提高了。从那时起，我再也没有回头过。
- Grank
1
我唯一认为可能成为技术“绊脚石”的事情是，如果你想使用除SQL Server之外的其他关系型数据库管理系统。（虽然可以通过解决方案来解决 - 请参见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。所以让我们希望他们这样做...
- KristoferA
1
一个真正的ORM应该将业务实体的设计与持久化介质分离开来。这样你就可以单独重构它们中的任何一个，并且只需要维护两者之间的映射关系。这减少了你需要为数据库变更而维护的应用逻辑代码量。
要使用Linq-to-SQL实现这种持久化无关的方法，你需要使用它生成的类作为DTO，并维护DTO和实体之间的映射逻辑。
有很多更好的ORM（比如NHibernate）采用了这种方法，大大减少了对DTO的需求。
要使用Linq-to-SQL实现这种持久化无关的方法，你需要使用它生成的类作为DTO，并维护DTO和实体之间的映射逻辑。
有很多更好的ORM（比如NHibernate）采用了这种方法，大大减少了对DTO的需求。
- Karthik Hariharan
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接