NHibernate与Linq to SQL

linq to sql强制您使用每个类模式的表。使用此模式的好处是,它快速且易于实现,并且使域基于现有数据库结构运行所需的工作量非常小。对于简单的应用程序,这是完全可以接受的(有时甚至更可取),但对于更复杂的应用程序,开发人员通常建议使用 domain driven design 相反的模式(这是NHibernate促进的)。

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

• 街机地址
• 西蒂
• 状态
• 拉链

现在,假设您还想为客户的邮寄地址添加列,那么您可以将以下列添加到客户表中:

• 邮件目录详细地址
• 邮递市
• 梅林状态
• 邮编

使用linq to sql,域中的客户对象现在将拥有这八列中每一列的属性。但是,如果您遵循一个域驱动的设计模式,那么您可能已经创建了一个地址类,并且让您的客户类拥有两个地址属性,一个用于邮件地址,另一个用于其当前地址。

这是一个简单的例子,但它演示了每个类的表模式如何导致一个有点臭的域。最后,由你决定。同样,对于只需要基本CRUD(创建、读取、更新、删除)功能的简单应用程序,Linq to SQL非常理想,因为它简单。但就我个人而言,我喜欢使用NHibernate,因为它有助于更清洁的领域。

编辑:@lomaxx-是的,我使用的示例非常简单,可以优化以与linq to sql很好地配合使用。我想尽可能地保持基本状态,把这一点带回家。重点仍然存在,尽管有几个场景让数据库结构决定域结构是一个坏主意,或者至少会导致次优的OO设计。

到目前为止,我们错过了两点:

• Linq to SQL不适用于Oracle 或除sqlserver之外的任何数据库。 但是,第三方确实为Oracle提供了更好的支持,例如 devArt's dotConnect , DbLinq , Mindscape's LightSpeed 和 ALinq . (我对这些没有任何个人经验)

• Linq to NHibernate 让你使用 Linq加了一种NHiberate,所以它可以 删除不使用的原因。

也新 fluent interface to Nhibernate 似乎可以减少配置nhibernate_s映射的痛苦。(去除NHiBiNIT的疼痛点)

更新

linq到nhiberate在nhiberate v3中更好,现在在 alpha . 看起来NHiberateV3可能在今年年底上市。

这个 Entity Frame Work 从.NET 4开始,它也开始看起来像一个真正的选项。

@凯文:我认为你所举的例子的问题在于你使用的数据库设计不好。我想您应该创建一个客户表和一个地址表,并规范化这些表。如果您这样做了,您就可以为您建议的场景明确地使用linq-to-sql。Scott Guthrie有一个 great series of posts on using 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改为SQL改为NHibernate。尤其是L2S实现对象的方式似乎比NHibernate的同上慢,而且变更管理也相当慢。对于不需要更改的特定场景,很难关闭更改管理。

如果要使用与DataContext断开连接的实体(例如,在WCF场景中),则在将它们重新连接到DataContext以更新更改时可能会遇到很多问题。我对NHibernate没有问题。

从L2S中我将错过的主要是代码生成,它使实体两端的关系保持最新。但我想也有一些工具可以让NHiberinate做到这一点…

你能解释一下你所说的“LINQ”是什么意思吗?

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

很多人把linq-to-sql称为linq,但这根本不正确。微软刚刚发布了linq to entities with.NET 3.5 SP1。另外,nhibernate有一个linq接口,所以您可以使用linq和nhibernate来获取您的数据。

通过linq,我假设您指的是linq to sql,因为linq本身没有与之相关联的数据库“going on”。它只是一种查询语言,有大量的语法成分使其看起来像SQL语言。

在非常基础的基本示例中,nhibernate和linq-to-sql似乎都解决了相同的问题。一旦你通过,你很快就会意识到,nhibernate支持许多功能,允许你创建真正丰富的领域模型。还有一个linq-to-nhibernate项目,它允许您使用linq以与使用linq-to-sql相同的方式查询nhibernate。

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

LinqToSQL的优点是快速从数据库模式中生成类,以便它们可以用作活动记录对象(请参见活动记录设计模式定义)。

nHibernate的优点是允许在对象建模和数据库建模之间实现灵活性。例如,可以对数据库进行建模,以最好地反映考虑性能的数据。虽然您的对象建模将使用领域驱动设计等方法最好地反映业务规则的元素。(见凯文·潘评论)

对于建模和/或命名约定较差的遗留数据库,Linq to SQL将把这些不需要的结构和名称反映到类中。然而,nhibernate可以用数据映射器隐藏这一混乱。

在数据库命名良好、复杂度较低的绿地项目中,LINQ to SQL是很好的选择。

但是你可以用 带自动映射的Fluent NHibernate 为了这个目的,映射和约定是一样的。在这种情况下,您不必担心任何带有XML或C的数据映射器,并让nHibernate根据您可以自定义的约定从您的实体生成数据库模式。

另一方面,linq到sql的学习曲线比nhibernate小。

或者你可以使用Castle ActiveRecords项目。我用它来为一个遗留项目增加一些新的代码已经有很短的时间了。它使用了NHibernate,并在活动记录模式上工作(我知道它的名字让人惊讶)。我没有尝试过,但我认为一旦你使用了它,如果你觉得有必要直接向NHibernate支持部门求助,对你的部分或全部项目来说,这样做不会太多。

正如你们所写的“对于一个并没有使用过它们的人” Linq to SQL易于使用,因此任何人都可以轻松使用它 它还支持程序,这在大多数情况下都有帮助。 假设您希望从多个表中获取数据,然后编写一个过程并将该过程拖动到设计器,它将为您创建所有内容, 假设您的过程名是“客户订单行项目”,它从这三个表中提取记录,然后只需编写

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

您也可以在foreach循环中使用records对象,这是nhibernate不支持的