实体框架2和NHibernate如何比较?

时间:2009-08-07 03:11:00

标签: nhibernate entity-framework ado.net

我基本上想知道如下事项:

  • 两者之间的优缺点?
  • 两个框架之间的相似点/不同点?
  • 他们在建筑上是如何相似/不同的?
  • 每个需要多少样板代码才能使用?
  • 与NHibernate相比,可以在Visual Studio之外有效地使用实体框架吗?与Visual Studio一起使用时,实体框架是否比NHibernate更有效?

注意:此问题涉及实体框架2(目前仍在开发中)。

1 个答案:

答案 0 :(得分:8)

免责声明:本文基于我目前对下一版Entity Framework的了解。这可能是不准确的,或者可能会改变,直到下一个版本实际被重新发布。

一般方法:

实体框架(EF)的主要方法是使用其图形设计器工具来创建实体数据模型,并生成域类以及从该模型进行映射。也支持其他方法,但这种工作方式可能永远是主要方法。

NHibernate(NH)是一个基于文本的工具,如果你不转向第三方软件进行代码生成,例如MyGeneration of CodeSmith,或者附加约定,则需要用户手动编写所有域类和映射。配置支持,例如Fluent NHibernate。

代码生成:

代码生成是标准EF使用的主要部分,可以使用他们的图形设计器工具,也可以使用他们的命令行工具。 GUI和命令行工具的可用性是一个优势,因为EF易于开始使用,并允许更高级的使用,可以自动化,例如在构建过程中。

NHibernate不支持代码生成,除了模式生成的东西,如果你想把它作为代码生成。如果你转向第三方软件,你可以获得代码生成。

数据库架构生成:

EF将允许用户从实体数据模型生成模式,从而为模型优先开发添加支持。 NHibernate已经有很长一段时间的架构生成支持。这里的不同之处在于如何创建“模型”,如前所述。

<强> LINQ:

EF将从v1改进他们糟糕的LINQ实现,NH现在已经达到了LINQ到NH的1.0版本,所以在这方面两者之间不应该有任何重大差异。

<强> POCO:

EF将为域驱动设计方法和与数据访问层分离的域类的使用提供更好的支持。但是,由于POCO不是EF的主要用例,我无法真正看到他们的POCO支持如何达到NHibernate的水平。 EF中的POCO支持还很年轻,对我而言,如果你是POCO / DDD的支持者并且你因为某种原因发现自己正在使用EF,那么感觉更像是奖励。

DDD人员为POCO开发构建了整个NHibernate框架,他们已经达到了2.1版,并且充分利用了Java端Hibernate的所有工作。很长一段时间,NHibernate可能仍然是DDD / POCO / ALT.NET人群的首选。

延迟加载:

EF的下一个版本将包括对自动延迟加载的支持。自动延迟加载一直是NHibernate的重要组成部分。

学习曲线:

这两个框架都很复杂且功能强大,因此需要很长时间才能掌握。但EF非常适合初学者,因为它通过其图形设计工具集成到Visual Studio中,并且因为它可以为您生成很多东西而无需了解框架的任何内容。但是,如果你想深入了解EF并真正学习框架,你应该准备花很多时间来使用它。

NHibernate有一个臭名昭着的学习曲线,但最近的一些改进已经减少了一点。既然LINQ to NH处于v1.0,那么对于刚接触NH的开发人员来说,查询语法将更容易理解,而Fluent NHibernate项目正在改进映射体验,甚至还在进行自动映射,这种情况越来越好。时间。