Linq to SQL 仍然是开发应用程序的可行选择吗？

Posted 2023-04-12

【中文标题】Linq to SQL 仍然是开发应用程序的可行选择吗？

【英文标题】：Is Linq to SQL still a viable choice for developing applications?

【发布时间】：2009-10-03 12:52:36

【问题描述】：

在使用 Ruby on Rails 进行了短暂的（有时是持续的）工作后，我再次阅读 .NET 方面的内容。我想知道在为新应用程序选择 ORM 时是否仍然可以选择 LINQ，或者我是否应该学习 NHibernate 之类的东西，它似乎仍然很强大。我知道 Linq 基本上已被实体框架所包含，但是当我尝试 EF（这是不久前）时，我发现它太重且太“鼠标驱动”（即与设计师一起玩很多）。我在 NHibernate 上观看了一些简短的截屏视频，我确实喜欢它强制执行的关注点分离以及可以保持模型干净的想法。

Linq 的语法虽然非常好，但它不是真正的 ORM，我不想学习那些当我可以学习正在使用或将要使用的东西时基本上已经过时的东西（EF 和/或 NHibernate，因为示例）。

那么，Linq 是否仍然应该考虑在应用程序中使用（让我们假设一些中等复杂性的东西；不是一个微不足道的应用程序，但不是一个巨大的任务；与 37Signal 的 Highrise 等基于 Web 的应用程序一样复杂）或有没有更好的东西值得一看？

【参考方案1】：

Linq 不是 ORM，Linq 很棒。如果可能，您很可能希望使用 Linq。

LinqToSql 是一个 ORM，尽管它的功能非常轻巧。它为您提供了基于 SQL Server 数据库定义的活动记录类型数据层类的基本（并且主要是一次性）代码生成。虽然它支持一些基本的 ORM 功能，但大多数其他您想要的功能，您都必须自己创建。

EntityFramework 也是一个 ORM。虽然它有一些 LinqToSql 的限制，但它也做了一些更好的事情和一些更糟糕的事情。当前的 V1 有许多限制，其中一些将在 Visual Studio 2010 的下一个版本 (V4) 中解决。

LinqToSql 或 EntityFramework 都不是成熟的、经过验证的 ORM。两者都有明显的缺点，您在进行大多数“正常”软件开发项目时可能会遇到这些缺点。

NHibernate 提供的功能比 Microsoft 的任何一种 ORM 都多得多，您会发现它几乎适用于任何“现实世界”情况。如果您喜欢 Microsoft 的 ORM 之后的 ActiveRecord 模式，NHibernate 也通过Castle ActiveRecord 支持。

这三个 ORM 都支持 Linq。

请注意。在项目中切换 ORM 可能既困难又昂贵，这取决于您将数据层与其他层分离的程度。例如，您不能轻易地从 LinqToSql 开始，然后当您遇到 LinqToSql 的众多限制之一时切换到例如 NHibernate，除非您非常聪明地了解如何将 ORM 与其余实现分离，这根据 ORM 可能会非常困难。

【参考方案2】：

您需要区分作为编程语言概念（语言集成查询）的 LINQ 和作为面向 SQL Server 的数据库映射（“ORM”）工具的 Linq-to-SQL。

LINQ 本身 - 作为一种技术 - 肯定会继续存在 - 毫无疑问。

Linq-to-SQL 有点不同，因为微软不会再将太多资源投入到它的进一步开发中。对于 .NET 4.0，他们推出了一些增强功能和错误修复，但没有什么大不了的。

因此，如果您的应用程序很小，并且您并没有真正设想它能够在生产中使用 10 年或更长时间，您仍然可以选择 Linq-to-SQL 作为一种非常可行且有用的技术，以便快速轻松地启动和运行- 只要您只需要 SQL Server 作为您的数据库后端。

如果您处于更加面向企业的环境中，如果您的应用可能会持续 10 年或更长时间，或者如果您需要异构数据库后端，或者如果您需要在数据库中的不同物理架构和对象之间进行映射域模型 - 然后选择 ADO.NET Entity Framework 和 Linq-to-Entities。它提供了比 Linq-to-SQL 更多的冲击力 - 代价是更高的学习曲线。

您的选择 - 这两种技术绝对是当今和未来 2、3、5 年构建应用程序的好方法 - 在那之后，所有的赌注都没有了 :-)

马克

【参考方案3】：

我相信 ***（仍然）在 LINQ to SQL 上运行，所以说它不是一个可行的选择有点奇怪。我在 WPF 和 ASP.NET 中用它做了一些演示，它很简单，易于使用。用直接 SQL 做不到的事情。

【讨论】：

同意，但 SO 是在 LINQ to SQL 还“新”的时候开发的，不是吗？

确实如此。但是 L2S 仍然得到支持和开发。

【参考方案4】：

我要补充一点，L2S 是您在 .NET 上的 one of the fastest options。考虑到支持的 LINQ 功能的质量，它可以是各种情况下的最佳选择。

【讨论】：

速度不应该是选择 ORM 的主要因素，因为*** ORM 的速度是相当的（EntityFramework 1.0/3.5 以生成性能不佳的 SQL 而闻名，但其他的则没有主要的、重要的性能缺陷）。

我完全同意如果速度相当，那不是主要因素。但是 NH 或 Subsonic 在您的*** ORM 列表中吗？

【参考方案5】：

LINQ to SQL 对于需要实现不太复杂的数据库访问层的开发人员来说是一个方便的选择（这是相当常见的情况）。 我们公司正在不断完善LINQ to SQL tecnology for Oracle, mysql, PostgreSQL and SQLite databases的实施。