NHibernate vs LINQ to SQL

Question

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

Answer 1

LINQ to SQL强制您使用每个类的表模式。使用此模式的好处是，它快速且易于实现，并且只需很少的工作就可以基于现有的数据库结构让您的域运行起来。对于简单的应用程序，这是完全可以接受的(通常甚至更可取)，但对于更复杂的应用程序，开发人员通常会建议使用domain driven design模式(这正是NHibernate提供的便利)。

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

• StreetAddress
• City
• State
• Zip

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

• MailingStreetAddress
• MailingCity
• MailingState
• MailingZip

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

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

编辑：@lomaxx -是的，我使用的示例过于简单，本可以进行优化以与LINQ to SQL很好地协同工作。我想把它保持在尽可能基本的状态，以便让大家明白这一点。不过，重点仍然是，在某些情况下，让数据库结构确定域结构不是一个好主意，或者至少会导致不太理想的OO设计。

Answer 2

到目前为止，我们忽略了两点：

除SqlServer外，

• LINQ to SQL不能与Oracle或任何数据库一起使用。然而，第三方确实为甲骨文提供了更好的支持，例如、、和。(我没有任何使用these)
• Linq to NHibernate的个人经验，它允许您使用带有Nhiberate的Linq，因此它可能会消除不使用的理由。

此外，新的fluent interface to Nhibernate似乎减少了配置Nhibernate映射的痛苦。(移除Nhibernate的一个痛点)

更新

Linq to Nhiberate在现在alpha中的Nhiberate v3中更好。看起来Nhiberate v3可能会在今年年底发货。

从.net 4开始，Entity Frame Work也开始看起来像一个真正的选择。

Answer 3

@Kevin:我认为你所展示的例子的问题在于你使用了一个糟糕的数据库设计。我原以为您会创建一个customer表和一个address表，并对这些表进行规范化。如果您做到了这一点，您就可以针对您所建议的场景使用Linq To SQL。斯科特·格思里有一个great series of posts on using Linq To SQL，我强烈建议你去看看。

我不认为你可以说Linq和NHibernate是互补的，因为这意味着它们可以一起使用，虽然这是可能的，但你最好选择一个并坚持下去。

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

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

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

使用linq需要注意的是，它只在.net 3.x中可用，并且只在VS2008中受支持。除了VS2005，NHibernate还提供了2.0和3.x版本。

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

自动为您执行此操作。