NHibernate与LINQ to SQL [英] NHibernate vs LINQ to SQL

问题描述

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

As someone who hasn't used either technology on real-world projects I wonder if anyone knows how these two complement each other and how much their functionalities overlap?

推荐答案

LINQ to SQL会强制您使用每类表模式.使用此模式的好处在于，它易于实现且易于操作，并且只需花费很少的精力即可使您的域基于现有的数据库结构运行.对于简单的应用程序，这是完全可以接受的(并且有时甚至更可取)，但是对于更复杂的应用程序，开发人员通常会建议使用模式(这是NHibernate促进的).

LINQ to SQL forces you to use the table-per-class pattern. The benefits of using this pattern are that it's quick and easy to implement and it takes very little effort to get your domain running based on an existing database structure. For simple applications, this is perfectly acceptable (and oftentimes even preferable), but for more complex applications devs will often suggest using a domain driven design pattern instead (which is what NHibernate facilitates).

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

The problem with the table-per-class pattern is that your database structure has a direct influence over your domain design. For instance, let's say you have a Customers table with the following columns to hold a customer's primary address information:

• 街道地址
• 城市
• 状态
• 邮编

现在，假设您也要为客户的邮寄地址添加列，以便在客户"表中添加以下列:

Now, let's say you want to add columns for the customer's mailing address as well so you add in the following columns to the Customers table:

• MailingStreetAddress
• 邮件城
• MailingState
• MailingZip

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

Using LINQ to SQL, the Customer object in your domain would now have properties for each of these eight columns. But if you were following a domain driven design pattern, you would probably have created an Address class and had your Customer class hold two Address properties, one for the mailing address and one for their current address.

这是一个简单的示例，但它演示了每类表"模式如何导致一个有点臭的域.最后，取决于您.同样，对于只需要基本CRUD(创建，读取，更新，删除)功能的简单应用程序而言，LINQ to SQL由于其简单性而非常理想.但是我个人喜欢使用NHibernate，因为它可以简化域.

That's a simple example, but it demonstrates how the table-per-class pattern can lead to a somewhat smelly domain. In the end, it's up to you. Again, for simple apps that just need basic CRUD (create, read, update, delete) functionality, LINQ to SQL is ideal because of simplicity. But personally I like using NHibernate because it facilitates a cleaner domain.

@lomaxx-是的，我使用的示例过于简单，可以进行优化以与LINQ to SQL一起使用.我想让它尽可能地基本，以使这一点成为现实.重点仍然是，尽管在某些情况下，让数据库结构决定您的域结构将不是一个好主意，或者至少会导致次优的OO设计.

@lomaxx - Yes, the example I used was simplistic and could have been optimized to work well with LINQ to SQL. I wanted to keep it as basic as possible to drive home the point. The point remains though that there are several scenarios where having your database structure determine your domain structure would be a bad idea, or at least lead to suboptimal OO design.

这篇关于NHibernate与LINQ to SQL的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！