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

Question

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

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

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

Answer 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，可能会非常困难。