NHibernate与EF（Entity Framework）的区别

NHibernate与EF（Entity Framework）的区别

概述

长久以来，程序员和数据库总是保持着一种微妙的关系，在商用应用程序中，数据库一定是不可或缺的元件，这让程序员一定要为了连接与访问数据库而去学习 SQL 指令，至少对于我而言，我觉得这是一个很不爽的事情。因此在信息业中有很多人都在研究如何将程序设计模型和数据库集成在一起，对象关系对应 (Object-Relational Mapping) 的技术就是由此而生，像Hibernate或NHibernate都是这个技术下的产物，而微软官方一直没有推出类似的框架，依旧依靠ADO.NET这个传统的数据访问工具。估计微软也听到了来自程序员的抱怨，于是从一个ObjectSpace（ObjectSpace最早在2005年？被提出，可以让应用程序可以用完全对象化的方法连接与访问数据库，其技术概念与NHibernate相当类似）的概念最后在2008年随.net framework 3.5 SP1发布了ADO.NET Entity Framework，一个附带有图形化设计器的面向实体数据库访问框架。

如图：

NHibernate

NHibernate 是一个面向.NET 环境的对象/关系数据库映射工具。对象关系映射(O/R Mapping，Object Relational Mapping)表示一种技术，用来把对象模型表示的对象映射到基于SQL 的关系模型数据结构中去。NHibernate是基于ms.net的O/R Mapping持久框架，它从基于Java的Hibernate项目移植而来。O/R Mapping就是把对象到映射关系数据库的记录，简单的说就是能实现把一个对象存储为数据表中的一条记录和由一条记录创建一个相应的对象，数据表中的数据就是对象的属性。

NHibernate不仅仅管理.NET 类到数据库表的映射（包括.NET 数据类型到SQL 数据类型的映射），还提供数据查询和获取数据的方法，大幅度减少我们开发时人工使用SQL和ADO.NET处理数据的时间。NHibernate的目标是对于开发者通常的数据持久化相关的编程任务，解放其中的95%。并请记住NHibernate作为数据库访问层，是与你的程序紧密集成的。

那么为什么要使用O/R Mapping？它与传统的DataSet/DataTable又有什么不同了？

  首先是设计上的不同，当使用O/R Mapping时，更多的是从对象的角度来设计程序，而把数据(对象的属性)存储的细节放在后面, 可以完全采用面向对象(OO)的方式来设计，而在使用DataSet/DataTable时，它只是存放数据的对象，看起来更像一个数据表，不能直观的表达业务概念。

NHibernate架构

NHibernate体系结构非常抽象的概览

展示了NHibernate在数据库和应用程序之间提供了一个持久层。

第一幅图好像非常简单？其实NHibernate是比较复杂的。我们了解两种极端情况，轻量级和重量级架构。再来第二幅图：轻量级体系，应用程序自己提供ADO.NET连接，并且自行管理事务。

最后一张图：重量级体系：所有的底层ADO.NET API都被抽象了。

Hibernate优点：

（1）对象/关系数据库映射(Basic O/R Mapping)

它使用时只需要操纵对象，使开发更对象化，抛弃了数据库中心的思想，完全的面向对象思想。

（2）透明持久化(Persistent)

带有持久化状态的、具有业务功能的单线程对象，此对象生存期很短。这些对象可能是普通的JavaBeans/POJO，这个对象没有实现第三方框架或者接口，唯一特殊的是他们正与（仅仅一个）Session相关联。一旦这个Session被关闭，这些对象就会脱离持久化状态，这样就可被应用程序的任何层自由使用。（例如，用作跟表示层打交道的数据传输对象。）           

（3）事务Transaction (org.Hibernate.Transaction)

应用程序用来指定原子操作单元范围的对象，它是单线程的，生命周期很短。它通过抽象将应用从底层具体的JDBC、JTA以及CORBA事务隔离开。某些情况下，一个Session之内可能包含多个Transaction对象。尽管是否使用该对象是可选的，但无论是使用底层的API还是使用Transaction对象，事务边界的开启与关闭是必不可少的。

（4）它没有侵入性，即所谓的轻量级框架。

（5）移植性会很好。

（6）缓存机制。提供一级缓存和二级缓存。

（7）简洁的HQL编程。

Hibernate缺点：

（1）Hibernate在批量数据处理的时候是有弱势。

（2）针对某一对象(单个对象)简单的查改删增，不是批量修改、删除，适合用Hibernate；而对于批量修改、删除，不适合用Hibernate，这也是OR框架的弱点;要使用数据库的特定优化机制的时候，不适合用Hibernate。

Entity Framework

 

在.Net Framework SP1微软包含一个实体框架（Entity Framework），此框架可以理解成微软的一个ORM产品。用于支持开发人员通过对概念性应用程序模型编程（而不是直接对关系存储架构编程）来创建数据访问应用程序。目标是降低面向数据的应用程序所需的代码量并减轻维护工作。

Entity Framework 应用程序有以下优点：

• 应用程序可以通过更加以应用程序为中心的概念性模型（包括具有继承性、复杂成员和关系的类型）来工作。
• 应用程序不再对特定的数据引擎或存储架构具有硬编码依赖性。
• 可以在不更改应用程序代码的情况下更改概念性模型与特定于存储的架构之间的映射。
• 开发人员可以使用可映射到各种存储架构（可能在不同的数据库管理系统中实现）的一致的应用程序对象模型。
• 多个概念性模型可以映射到同一个存储架构。
• 语言集成查询支持可为查询提供针对概念性模型的编译时语法验证。

实体框架Entity Framework 是 ADO.NET 中的一组支持开发面向数据的软件应用程序的技术。在EF中的实体数据模型（EDM）由以下三种模型和具有相应文件扩展名的映射文件进行定义。

• 概念架构定义语言文件 (.csdl) -- 定义概念模型。
• 存储架构定义语言文件 (.ssdl) -- 定义存储模型（又称逻辑模型）。
• 映射规范语言文件 (.msl) -- 定义存储模型与概念模型之间的映射。

实体框架 使用这些基于 XML 的模型和映射文件将对概念模型中的实体和关系的创建、读取、更新和删除操作转换为数据源中的等效操作。EDM 甚至支持将概念模型中的实体映射到数据源中的存储过程。它提供以下方式用于查询 EDM 并返回对象：

• LINQ to Entities -- 提供语言集成查询 (LINQ) 支持用于查询在概念模型中定义的实体类型。
• Entity SQL -- 与存储无关的 SQL 方言，直接使用概念模型中的实体并支持诸如继承和关系等 EDM 功能。
• 查询生成器方法 --可以使用 LINQ 风格的查询方法构造 Entity SQL 查询。

下图演示用于访问数据的实体框架体系结构：

我认为的一些缺点：

·                 Edmx包含了所有对象的csdl，ssdl，msl文件，过于庞大，如果要手动修改这个文件，一不小心，眼睛看花了，就改错了。（和数据集一样的毛病）。

·                 目前EF支持表、试图、存储过程，其他的对象不支持，而且对使用存储过程有很多限制（目前有EFExtension提供了更多对象的支持）。

·                 除了MS SQL Server可直接提供这种可视化的设计界面外，其他的数据库目前还没有提供可视化设计界面（但可以自己来实现，后面介绍）。

·                 性能问题。（网上看到有说比ADO.Net慢700百，又有人说比ADO.net快的，具体情况我还没测试过, 但我觉得像这个些类型的框架，性能肯定是比上原生态的ADO.net慢）

案例：

Entity Framework 利用了抽象化数据结构的方式，将每个数据库对象都转换成应用程序对象 (entity)，而数据字段都转换为属性 (property)，关系则转换为结合属性 (association)，让数据库的 E/R 模型完全的转成对象模型，如此让程序设计师能用最熟悉的编程语言来调用访问。而在抽象化的结构之下，则是高度集成与对应结构的概念层、对应层和储存层，以及支持 Entity Framework 的数据提供者 (provider)，让数据访问的工作得以顺利与完整的进行。ADO.NET Entity Framework 以 Entity Data Model (EDM) 为主，将数据逻辑层切分为三块，分别为 Conceptual Schema, Mapping Schema 与 Storage Schema 三层： 　　(1) 概念层：负责向上的对象与属性显露与访问,让上层的应用程序码可以如面向对象的方式般访问数据。这部分由设计器自动生成，表现在一系列的类。 　　(2) 对应层：将上方的概念层和底下的储存层的数据结构对应在一起,负责将上层的概念层结构以及下层的储存体结构中的成员结合在一起，以确认数据的来源与流向。这部分由描述语言实现，可以自由修改。 　　(3) 储存层：依不同数据库与数据结构，而显露出实体的数据结构体，负责与数据库管理系统 (DBMS) 中的数据表做实体对应 (Physical Mapping)，让数据可以输入正确的数据来源中，或者由正确的数据来源取出。
对于访问者（上层的逻辑）而言，可以使用三种方式访问EDM：Entity Client，Object Context 以及LINQ
1. Entity Client（数据库操作访问方式）

Entity Client是 ADO.NET Entity Framework 中的本地用户端 (Native Client)，它的对象模型和 ADO.NET 的其他用户端非常相似，一样有 Connection, Command, DataReader 等对象，但最大的差异就是，它有自己的 SQL 指令 (Entity SQL)，可以用 SQL 的方式访问 EDM，简单的说，就是把 EDM 当成一个实体数据库。

EntityConnectionStringBuilder entityBuilder = new EntityConnectionStringBuilder(); entityBuilder.Provider = providerName; entityBuilder.ProviderConnectionString = providerString; using (EntityConnection conn = new EntityConnection(entityBuilder.ToString())) { conn.Open(); EntityCommand comm = new EntityCommand("SELECT * FROM Student", conn); EntityDataReader reader = comm.ExecuteReader(); conn.Close(); }

2. Object Context（对象操作访问方式）
由于 Entity Client 太过于制式，而且也不太符合 ORM 的精神，因此微软在 Entity Client 的上层加上了一个供编程语言直接访问的界面，它可以把 EDM 当成对象般的访问，此界面即为 Object Context (Object Service)，在 Object Context 中对 EDM 的任何动作，都会被自动转换成 Entity SQL 送到 EDM 中执行。我个人比较倾向于使用这种方式。

DBForEntityEntities db = new DBForEntityEntities(); ObjectQuery<Student> que = db.Student.Where("it.StName=@P1", new ObjectParameter("P1", "N1")); foreach (Student st in que) { //TO DO SOMETHING }

3. LINQ（LINQ操作的访问方式）
Object Context 将 EDM 的访问改变为一种对对象集合的访问方式，这也就让 LINQ 有了发挥的空间，因此 LINQ to Entities 也就由此而生，简单的说，就是利用 LINQ 来访问 EDM，让 LINQ 的功能可以在数据库中发挥。

DBForEntityEntities db = new DBForEntityEntities(); ObjectQuery<Student> students = db.Student; IQueryable<Student> Que = from p in students select p;

作者：记忆逝去的青春 出处：http://www.cnblogs.com/lukun/ 本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，如有问题，可以通过http://www.cnblogs.com/lukun/  联系我，非常感谢。