使用Entity Framework 4进行代码优先开发
使用Entity Framework 4进行代码优先开发
【原文地址】Code-First Development with Entity Framework 4 【原文发表日期】 2010/7/16 4:35 AM
.NET 4随带发布了一个改进版的Entity Framework（EF）— 一个位于System.Data.Entity命名空间的数据访问函数库。
当Entity Framework在.NET 3.5 SP1里第一次发布的时候，很多程序员给我们提供了反馈，指出他们认为在第一个版本中不足的地方。SQL团队积极听取这些意见，并且在.NET 4的版本里吸取了意见。 EF4里一些重大改进包含有：
· 支持简单CLR对象（POCO）：现在你不需要基类或者数据持久化属性就可以定义实体了。 · 支持延迟加载：现在你可以即时加载子对象，而不是预先加载它们。
· 支持N-层技术和自跟踪实体：用来处理在层间传输实体或者无状态Web调用的情况。
· 更好的SQL语句生成和存储过程的支持：EF 4执行的是更快的SQL，而且还包括了对更好的存储过程集成支持。
· 支持自动的单复数名词转换：EF4支持对表名自动转换单复数（例如：Categories -> Category）。 · 更佳的可测性：在EF4里，现在可以更容易地根据接口来创建模拟对象。 · 支持更多的LINQ操作符：EF4现在支持LINQ所有的操作符。
Visual Studio 2010同时也提供了更丰富的针对EF的设计器和工具。VS 2010的EF设计器同时支持“数据库优先”的开发模式—即通过已有的数据库在设计界面上创建模型层。和支持“模型优先”的开发模式—即你在设计界面上先定义好模型层，然后再根据它生成数据库的结构。
使用EF进行代码优先开发
除了支持以设计器为基础的开发流程，EF 4还支持一个以代码为中心的开发方案，我们称它为“代码优先开发”。代码优先开发开启了一个美好的开发流程。它允许你： · 不需要打开设计器或者定义一个XML映射文件就可以开发程序。
· 只需要写一个简单的类就可以定义模型对象，而不要求有任何基类。 · 使用“惯例高于配置”的方式来实现数据库持久化，不需要显式配置任何东西。
· 也可以有选择性的复写基于惯例的持久化，并提供一个更流畅的API来完全定制持久化映射。 要使用EF的“代码优先开发”概念，当前你需要额外下载一个运行在.NET 4内置EF之上的工具。“代码优先”函数库的CTP 4版本已于本周发布，你可以从这里下载。
你可以在VS 2010的任一个.NET 4项目中使用它（包括ASP.NET Web窗体项目和ASP.NET MVC）。
手把手教程：使用代码优先的方式创建NerdDinner
去年我写了一篇ASP.NET MVC 1.0的教程，发表在博客和一本书里。这篇教程捋了一遍创建一个叫做“NerdDinner”的简单程序的过程，这个程序方便人们在线组织、主办和参加餐会。可以在这里参阅我原先的ASP.NET V1 NerdDinner教程。新书ASP.NET MVC 2高级编程也包含了更新过的教程。 这篇NerdDinner教程原先使用的是“数据库优先”的方式，也就是预先定义好数据库结构，然后使用Visual Stduio设计器创建LINQ to SQL或LINQ to Entities等模型对象来做映射。
下面我将演示如何用EF 4的“代码优先”的方式来创建NerdDinner的模型层和数据库结构，然后使用ASP.NET MVC创建一个增删改查程序。
我们将一步一步地创建这个程序，本文的最后有完整示例代码的下载链接。
第一步：新建一个空的ASP.NET MVC 2程序
我们从在Visual Studio 2010新建一个ASP.NET MVC 2项目开始，选择文件 -> 新项目并使用“ASP .NET MVC 2空 Web 应用程序”项目模板就行了。
这样就会新建一个空的ASP.NET MVC 2工程，里面没有什么控制器、模型和视图。
下一步我们将定义NerdDinner“模型”——表示程序中数据的对象，以及包含验证机制和业务规则等的逻辑。模型是基于MVC程序的“心脏”，实际上掌控了程序的行为。我们将使用EF 4新的“代码优先”方式来创建这个模型层。
第二步：创建模型
现在假设我们尚未创建数据库，从头开始创建NerdDinner程序。 我们不需要从数据库开始
当使用代码优先的开发流程时，我们不需要从先创建数据库或者定义数据库结构来开始程序开发。而可以从定义最适合我们程序的模型对象的标准.NET类开始——免除在里面混杂数据持久化逻辑的烦恼。
创建模型类型
NerdDinner是一个小程序，所需要的数据存储非常简单。我们希望能定义和存储代表人们可参加的事件——“Dinners（餐会）”。我们还希望能够定义和存储参加餐会的人员——“RSVP”，用来跟踪有兴
趣参加特定餐会的人。
让我们来创建两个类（Dinner和RSVP）来表现这个概念。在我们的ASP.NET MVC项目中添加两个类——“Dinner”和“RSVP”就可以了：
上面的“Dinner”和“RSVP”模型类就是“简单CLR对象”（即POCO）。它们不需要继承什么基类或者实现什么接口，而且里面定义的属性都是标准的.NET数据类型。里面没有添加数据持久化属性和操作数据的代码。
不需要在定义模型类时将他们绑定到特定的数据库、数据库API和数据库结构的功能的确很好，很强大——而且也让我们有了更弹性的数据访问方式。这样我们就能专注于程序和业务需求上，而不用过多考虑持久化的实现方式。另外，它还为我们提供了更换数据库结构或者存储实现方式的弹性空间—不需要重写模型对象或者与它们交互的代码。 创建Context类来处理数据持久化
我们已经定义了两个POCO模型类，现在让我们创建一个类来处理在数据库获取或保存Dinner和RSVP实例的工作。
我们将这个类命名为“NerdDinners”。它继承于DbContext基类，并且定义了两个公开属性——一个用来公开Dinner对象集合，另外一个公开RSVP对象集合：
上面用到的DbContext和DbSet类是EF 4代码优先函数库自带的。你需要添加对
System.Data.Entity.CTP程序集的引用，它位于目录\\Program Files\\Microsoft ADO.NET Entity Framework Feature CTP4\\Binaries中。另外在“NerdDinners”类型定义文件中，你需要添加“using System.Data.Entity”命名空间的引用。 这就是所有我们需要编写的代码了
上面三个类就是为我们NerdDinner程序实现一个基本的模型和数据持久层所需要的所有代码了。我们不需要配置额外的数据库结构影射信息，不需要运行任何工具，不需要编写什么XML文件，不需要用什么设计器来使用我们的类在数据库中获取、更新和存储数据。
基于惯例的持久化影射
不需要写什么额外代码，不需要创建什么XML文件，不需要运行什么工具来在数据库中映射我们的模型类。你可能会问，这可能吗？
默认情况下，EF代码优先库支持一个“惯例高于配置”的方式，它使用常见的映射习惯，从而避免显式地做任何配置。如果你想使用自定义的数据库映射规则的话，可以复写这些惯例。但如果你使用惯例的话，你会发现你自己需要写的代码真的很少，在不需要添加额外的代码和配置的前提下，90%的常见情况都可以正常工作。
在上面我们的例子当中，NerdDinner Context类默认会将“Dinners”和“RSVPs”属性映射为数据库的“Dinners”和“RSVPs”数据表。“Dinners”表里每一行都被映射成“Dinner”类型的一个实例。当然啦，“RSVPs”表里每一行都被映射成“RSVP”类型的一个实例。“Dinner”和“RSVP”类型里的属性也就随之被映射成“Dinners”和“RSVPs”表里的列。
EF支持的其它的惯例包括通过常见命名模式自动识别主键和外键（例如：根据Dinner类里的ID或者DinnerID属性推断出主键）。EF还灵巧地支持在两个模型间绑定相联关系的惯例。这里有一篇EF团队的博客讲解了所支持的默认惯例的工作方式。
使用我们模型的代码示例
前面我们创建的三个类包含了所有实现NerdDinner模型和数据持久化的所有代码。现在我们来看一