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 强制您使用 table-per-class 模式.使用这种模式的好处是它可以快速且容易地实现，并且只需很少的努力就可以让您的域基于现有的数据库结构运行.对于简单的应用程序，这是完全可以接受的(通常甚至更可取)，但对于更复杂的应用程序，开发人员通常会建议使用 领域驱动设计 模式代替(这是 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:
- 邮寄街道地址
- MailingCity
- 邮件状态
- 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屋！
