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

Laz*_*Laz 3 nhibernate ado.net entity-framework

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

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

注意:此问题涉及实体框架2(目前仍处于开发阶段).

Eri*_*ebo 8

免责声明:本文基于我目前对实体框架下一版本的了解.这可能是不准确的,或者可能会改变,直到下一个版本实际上被重新启动.

一般的做法:

实体框架(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项目正在改进映射体验,甚至还在进行自动映射,这种情况越来越好.时间.

  • 对于大多数人来说这是一个很好的答案(+1),但我不得不对LINQ持不同意见.虽然没有LINQ可以*使用EF,但我不知道有谁真正做过它.在EF,你将生活和呼吸LINQ.在NH,OTOH中,大多数用户不使用LINQ,新发布的LINQ to NH非常有限(在工作中有一个不太有限且完全独立的*实现).此外,EF围绕持久性/传输的价值对象(包括ORM和数据服务方面)构思,而NH则是更"传统"的ORM. (2认同)