NHibernate 与 LINQ to SQL

StackOverflow https://stackoverflow.com/questions/26971

题

作为一个没有在现实项目中使用过这两种技术的人，我想知道是否有人知道这两者如何互补以及它们的功能有多少重叠？

有帮助吗？

解决方案

LINQ to SQL 强制您使用每类表模式。使用此模式的好处是它可以快速且轻松地实现，并且只需很少的努力就可以让您的域基于现有的数据库结构运行。对于简单的应用程序，这是完全可以接受的（通常甚至更好），但对于更复杂的应用程序，开发人员通常会建议使用 领域驱动设计 模式（这正是 NHibernate 所促进的）。

每类表模式的问题在于您的数据库结构对您的领域设计有直接影响。例如，假设您有一个 Customers 表，其中包含以下列来保存客户的主要地址信息：

  • 街道地址
  • 城市
  • 状态
  • 压缩

现在，假设您还想添加客户邮寄地址的列，因此您将以下列添加到客户表中：

  • 邮寄街道地址
  • 邮件城
  • 邮寄状态
  • 邮寄邮编

使用 LINQ to SQL，域中的 Customer 对象现在将具有这八列中每一列的属性。但是，如果您遵循域驱动设计模式，则可能会创建一个 Address 类，并让您的 Customer 类保存两个 Address 属性，一个用于邮寄地址，一个用于当前地址。

这是一个简单的示例，但它演示了每类表模式如何导致有点臭的域。最后，这取决于你。同样，对于只需要基本 CRUD（创建、读取、更新、删除）功能的简单应用程序，LINQ to SQL 因其简单性而成为理想选择。但我个人喜欢使用 NHibernate，因为它有利于更干净的领域。

编辑：@lomaxx - 是的，我使用的示例很简单，可以进行优化以与 LINQ to SQL 很好地配合使用。我想尽可能保持基本的内容以阐明要点。但重点仍然是，在某些情况下，让数据库结构决定域结构是一个坏主意，或者至少会导致次优的 OO 设计。

其他提示

到目前为止，有两点被忽略了：

还有新的 Nhibernate 的流畅接口 似乎让配置 Nhibernate 的映射变得不那么痛苦。（解决Nhibernate的痛点之一）

更新

Linq to Nhiberate 在 Nhiberate v3 中更好，现已发布 α. 。看起来 Nhiberate v3 可能会在今年年底发布。

这 实体框架 从 .net 4 开始，它也开始看起来像是一个真正的选择。

@凯文：我认为您所呈现的示例的问题在于您使用了糟糕的数据库设计。我本以为您会创建一个客户表和一个地址表并对这些表进行规范化。如果您这样做，您绝对可以将 Linq To SQL 用于您建议的场景。斯科特·格思里有一个 有关使用 Linq To SQL 的精彩系列文章 我强烈建议你检查一下。

我不认为您可以说 Linq 和 NHibernate 相辅相成，因为这意味着它们可以一起使用，虽然这是可能的，但您最好选择其中之一并坚持使用它。

NHibernate 允许您以高度灵活的方式将数据库表映射到域对象。它还允许您使用 HBL 查询数据库。

Linq to SQL 还允许您将域对象映射到数据库，但它使用 Linq 查询语法来查询数据库

这里的主要区别是 Linq 查询语法是 编译器在编译时进行检查，以确保您的查询有效。

使用 linq 需要注意的一些事情是它仅在 .net 3.x 中可用，并且仅在 VS2008 中受支持。NHibernate 有 2.0 和 3.x 以及 VS2005 版本。

使用 NHibernate 需要注意的一些事情是它不会生成域对象，也不会生成映射文件。您需要手动执行此操作。Linq可以
自动为您执行此操作。

Fluent NHibernate 可以根据简单的约定生成映射文件。无需 XML 编写且强类型。

我最近参与了一个项目，出于性能原因，我们需要从 Linq To SQL 更改为 NHibernate。特别是 L2S 实现对象的方式似乎比 NHibernate 的同上慢，并且变更管理也相当慢。对于不需要的特定场景，很难关闭变更管理。

如果您打算使用与 DataContext 断开连接的实体（例如在 WCF 场景中），则在再次将它们连接到 DataContext 来更新更改时可能会遇到很多麻烦。我对 NHibernate 没有任何问题。

L2S 中我最怀念的是代码生成，它使实体两端的关系保持最新。但我想 NHibernate 也有一些工具可以做到这一点......

您能澄清一下“LINQ”的含义吗？

LINQ 不是一种数据访问技术，它只是一种支持作为本机构造进行查询的语言功能。它可以查询任何支持特定接口的对象模型（例如I可查询）。

许多人将 LINQ To SQL 称为 LINQ，但这根本不正确。Microsoft 刚刚发布了带有 .NET 3.5 SP1 的 LINQ To Entities。此外，NHibernate 有一个 LINQ 接口，因此您可以使用 LINQ 和 NHibernate 来获取数据。

对于 LINQ，我假设您指的是 LINQ to SQL，因为 LINQ 本身没有与之关联的数据库“运行情况”。它只是一种查询语言，具有大量语法糖，使其看起来像 SQL。

在非常基本的基本示例中，NHibernate 和 LINQ to SQL 似乎都在解决相同的问题。一旦您通过了，您很快就会意识到 NHibernate 支持许多功能，使您能够创建真正丰富的域模型。还有一个 LINQ to NHibernate 项目，允许您使用 LINQ 查询 NHibernate，其方式与使用 LINQ to SQL 的方式大致相同。

首先让我们分开两个不同的东西：数据库建模关注数据，而对象建模关注实体和关系。

Linq-to-SQL 的优点是可以从数据库模式快速生成类，以便它们可以用作活动记录对象（请参阅活动记录设计模式定义）。

NHibernate 的优点是允许对象建模和数据库建模之间具有灵活性。可以对数据库进行建模，以最好地反映您的数据，例如考虑性能。虽然您的对象建模将使用领域驱动设计等方法最好地反映业务规则的元素。（见彭凯文评论）

对于建模和/或命名约定较差的遗留数据库，Linq-to-SQL 会将这种不需要的结构和名称反映到您的类中。然而 NHibernate 可以通过数据映射器隐藏这种混乱。

在数据库具有良好命名和低复杂性的新建项目中，Linq-to-SQL 可能是不错的选择。

不过你可以使用 具有自动映射功能的 Fluent NHibernate 出于同样的目的，将映射作为约定。在这种情况下，您不必担心使用 XML 或 C# 的任何数据映射器，并让 NHibernate 根据您可以自定义的约定从您的实体生成数据库模式。

另一方面，Linq-to-SQL 的学习曲线比 NHibernate 小。

或者您可以使用 Castle ActiveRecords 项目。我已经使用它一段时间来为遗留项目增加一些新代码。它使用 NHibernate 并适用于活动记录模式（鉴于我知道它的名字，令人惊讶）。我还没有尝试过，但我认为一旦您使用了它，如果您觉得需要直接转向 NHibernate 支持，那么对于部分或全部项目来说这样做并不会太多。

正如您所写的“对于尚未使用其中任何一种的人”，linq to sql易于使用，因此任何人都可以轻松地使用它，也支持过程，这在大多数情况下都可以帮助过程。假设您想从一个以上的表中获取数据，然后编写一个过程并将该过程拖动到设计器，并且它将为您创建所有内容，假设您的过程名称是“ Cultience_order_order_lineItem”，从所有这三个表中获取记录，然后只需写入

MyDataContext db = new MyDataContext();
List<CUSTOMER_ORDER_LINEITEMResult> records = db.CUSTOMER_ORDER_LINEITEM(pram1, param2 ...).ToList<CUSTOMER_ORDER_LINEITEMResult>();

您也可以在 foreach 循环中使用记录对象，NHibernate 不支持该对象

许可以下： CC-BY-SA 和 归因
不隶属于 StackOverflow
scroll top