2009-08-07 97 views
3

我基本上想知道的东西,如:实体框架2和NHibernate如何比较?

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

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

+0

[我是否应该使用实体框架4.0?](http://izlooite.blogspot.com/2011/04/should-i-ever-use-entity-framework-40.html) – 2011-04-23 15:31:48

回答

8

免责声明:这篇文章是基于我目前的实体框架的下一个版本将是什么样的知识。这可能是不准确的,或者可能会改变,直到下一个版本实际上被转移。

一般方法:

实体框架(EF)的主要方法是使用自己的图形设计工具来创建一个实体数据模型,并从该模型生成域类以及映射。还有其他方法的支持,但这种工作方式可能永远是主要方式。 (NH)是一个基于文本的工具,它需要用户手动编写所有的域类和映射,如果你不转向用于代码生成的第三方软件,比如CodeSmith的MyGeneration或其他约定通过配置支持,比如Fluent NHibernate。

代码生成:

代码生成标准EF使用的主要部分,或者通过使用他们的图形设计工具或使用他们的命令行工具。 GUI和命令行工具的可用性是一个优点,因为使EF易于入门,并允许更高级的使用,例如在构建过程中可以实现自动化。如果要计算为代码生成

代码生成不被支持的NHibernate,除了架构生成的东西。如果你转向第三方软件,你可以获得代码生成。

数据库架构生成:

EF将增加对模型首先开发的支持,允许用户生成从实体数据模型架构。 NHibernate已经有很长一段时间的模式生成支持。如前所述,这里的区别在于如何创建“模型”。

LINQ:LINQ的

EF将有所改善,从V1和NH其怪诞的LINQ实现现在已经达到了1.0版NH,所以不应该有这方面的任何两者之间的主要区别。

POCO:

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

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

延迟加载:

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

学习曲线:

两个框架是复杂和强大,因此需要很长的时间才能掌握。但EF对初学者非常友好,因为它通过其图形设计工具集成到Visual Studio中,并且因为它可以为您生成很多东西,而不必知道关于框架的任何内容。但是,如果您想深入了解EF并真正了解该框架,则应该准备花费大量时间使用它。 NHibernate有一个臭名昭着的学习曲线,但最近的一些改进已经减少了一点。现在,LINQ to NH在v1.0,查询语法对于新开发NH的开发人员来说更容易理解,而Fluent NHibernate项目正在改进映射体验,甚至在自动映射上工作,自动映射越来越好,所有时间。

+2

这是一个很好的答案(+1),但我不同意LINQ。尽管可以*不使用LINQ来使用EF,但我不知道有谁已经完成了它。在EF中,你将生活和呼吸LINQ。在NH,OTOH中,大多数用户不使用LINQ,而新发布的LINQ to NH非常有限(在作品中有一个较少限制和*完全独立的*实现)。此外,EF基于持久性/运输价值对象(包括ORM和数据服务方面)的思想而构建,而NH则是一个更“传统”的ORM。 – 2009-08-07 12:57:34