【IT168 技术】记得去年初就开始关注Entity Framework，那时只是简单测试了一下，发现较之Nhibernate不太成熟。当时的EF主要表驱动方式开发，过度依赖edm文件，并且数据层耦合了模型层，让一些MVC分层用户痛苦不堪。微软从Oxite1项目发展到Oxite2也在这个DAL与MODEL的理不清的关系上做过徘徊，只好在EDM的基础上直接实现BLL。由于EntityObject模型与ObjectContext耦合，在N层架构构中EntityObject直接提供给客户端使用的话，那ObjectContext在客户端也会被调用，因此这个时候只能通过DTO对象的方式解决，而毕竟大部分EntityObject是可以直接传递使用的，而不是一定通过DTO传递。

　　我们看看现在的EF4.0和EF4.1有哪些进步，先来解释一些名词

　　EDM文件

　　EDM是实体数据关系映射的XML文件，不同于Nhibernate每个对象单独映射了一个XML文件。EDM主要有三部分构成CSDL，SSDL，MSL。CSDL表面的是实体数据模型结构，SSDL表示对应的数据存储的架构，CSDL实体与SSDL数据结构的关系通过MSL映射实现。EDM是通过ADO.NET 实体数据模型生成的

　　生成EDM文件的方式有两种，一种基于是数据库，一种是创建空EDM模型。前者就是后面要提到的DataBase First方式，后者是Model First方式。

　　针对创建好的EDM模型最终要生成代码，生成代码的工具不同，生成的代码也不同。看看下面几种生成方式，都于基于EDM模型生成的。

　　ADO.NET 实体数据模型 最初EF的方式，实体模型EntityObject与ObjectContext耦合在一起，不适合分层使用。

　　ADO.NET 自跟踪实体生成器 分离生成基于POCO的SelfTrackingEnityObject模型和ObjectContext (这种方试即使设置了延迟加载也无法加载关联导航属性，要在使用时手动加载)

　　ADO.NET DbContext Generator 分离生成纯POCO模型和轻型DbContext。DbContext较之ObjectContext比较简洁，并且POCO可以充分利用。

　　这就是我为什么选ADO.NET DbContext Generator 的原因，我们再看看EF框架的划分的模式：

• DataBase First
• Model First
• Code First

　　DataBase First 传统的表驱动方式创建edm，然后通过edm生成模型和数据层代码。除生成实体模型和自跟踪实现模型，还支持生成纯POCO模型和轻型DbContext。

　　Model First 先创建EDM模型，再生成DDL数据库脚本和模型和数据层代码。除生成实体模型和自跟踪实现模型，支持生成纯POCO模型和轻型DbContext。

　　Code First 手动创建POCO模型，数据层DbContext及映射关系，通过Database.SetInitializer生成数据库，这种方式较灵活，但是代码工作较多。

　　虽然Code First灵活，但是我们不可能手工去写大量的POCO类和映射关系。如果借助其它ORM工具生成Code First的需要POCO类，为什么试试Model First生成Code First需要的代码呢?