LINQ to SQL下行和限制

Question

使用Linq to Sql编写更传统的数据层，通过.NET SQL Server数据提供程序调用存储过程/使用动态SQL，有什么缺点和局限？

这些优点已有详细记载，但我发现很少有人讨论过人们所遇到的现实问题。

请注意，我不是在讨论与NHibernate和Subsonic等O / R映射器的比较。

Answer 1

有一些 - 不确定这些对你来说是否重要：

• 仅限SQL Server作为后端
• 至少需要运行.NET 3.5才能运行
• 有些限制，表格严格按1：1（一个表=一个类）
进行映射

但同样 - 这些只是限制，但很多人（包括我自己）可以忍受那些没有问题的人 - 至少对于某种类型的项目而言。

如果你需要更多的灵活性（更多的数据库后端，更细粒度的映射），你一定要看看NHibernate或者后来的实体框架4.它们提供更多的功能和更多的冲击 - 但它们也更难学习

另一方面，Linq-to-SQL也有很多专业人士：

• 视觉设计师使其非常易于使用
• 使用LINQ，比使用直接ADO.NET和sprocs
更有效率

但我相信你很清楚这些专业方面，对吗？ :-)

Answer 2

我发现的最大问题是您似乎需要将数据库表拖放到设计器上，并且直接访问dbml文本并不容易。有很多次我在表中添加了一个列并想要更新它，只需要从设计器中删除该表，重新添加它，并重新映射我已经完成的任何自定义关联。

如果有人可以告诉我如何轻松获取dbml文本，我很想知道如何做到这一点。

另一件令我烦恼的事情是，如果我得到“字符串或二进制数据可能会被截断”错误，我无法判断哪一列导致错误，让我玩一个试错游戏。

Answer 3

Linq对SQL的主要缺点是随着ADO.Net实体框架的出现带来的不确定性 - 除非情况发生变化，否则有传言称Linq对SQL的未来是多云的，因为MS正专注于实体框架并从Linq迁移到SQL。

我已经转移到实体框架，直到情况变得更加清晰，我在主要项目上谨慎使用Linq to SQL。