使用Entity. Framework编程(2)(3)

ponentModel.DataAnnotations程序集。因此，这些数据验证功能是.Net程序集的的内置特性。

例如，"Required"特性在.NET4的程序集中，而不在EntityFramework.dll程序集里。因此，如果你在MVC应用程序中使用的Code First类，并且忽略填写一个必须输入的属性，MVC用户界面验证会响应，你可以在图2-3看到。

DbContext还提供了一个验证API，具有服务器端验证的能力，这与使用Data Annotations特性标识还是使用Fluent API来配置类是没有关系的。但是，使用Data Annotations时,MVC与特性更好地配合，实现一些验证API的功能。验证API的细节内容不包括在这本书中，本书的重点在于Code First建模，你可在另一本书:Entity Framework:DbContext找到与验证API有关的信息。

使用Fluent API 配置Code First

使用Data Annotations配置很简单，也可能是你想要的。但是Data Annotations只能获得一部分配置的功能。这时,Fluent API可以提供更多的功能,基于这个原因你可能会愿意用它. 小贴士：Fluent API是什么?

Fluent API并非专用于Code First或EF框架。Fluent API的基本思路是使用链方法调用程序代码，这样代码很容易被开发者所阅读。每一个调用的返回类型都定义为下个调用的有效方法.例如,在Code First的Fluent API中,你可以使用Entity方法选择一个实体来配置.智能感知将会显示出所可以用来配置的方法.如果你使用属性方法选择属性来配置,你就看到所有为特定属性所配置的方法.

还有另一个原因解释为什么开发者首选Fluent API。在将标记应用到你的美妙域类上时,需要定义越来越多的烦人的标记。目前还只是一些验证逻辑,当你学到更多Data Annotations配置特性的时候,你就会发现需要更多的信息指导类如何映射到数据库。如果你喜欢清洁的类,不想让类包含那么多的标记，就可以选择Fluent API。Code First的一个优势就是能够使用自己的类构建EF框架，一个充斥着数据库表名或列类型的类显然不够简洁，Fluent API解决了这一问题,我们来看这是如何实现的。

小贴士：跟随Data Annotations还是跟随Fluent API ？

在本书后续内容中,你将会看到很多例子来说明如何配置映射,有Data Annotations的,也有使用Fluent API的.

许多映射只能通过Fluent API获得.如果你在VS中跟随我们学习,强烈推荐您创建两个单独的解决方案。否则,当使用了Data Annotation中还想看看在Fluent API中同样的配置效果,你就不得不注释掉有关代码。然后当你使用另一个Data Annotation特性标记，你又不得不注释掉Fluent API代码.在注释与取消注释之间来回调整,万一出现错误就会导致抛出异常,要么是配置重复要么是配置丢失，可能会非常麻烦。

这就意味着在创建新类或添加新方法时需要进行许多必要的复制/粘贴操作.也意味着Data Annotations 只能应用于一个解决方案而Fluent 配置被强制用于另一个.

如果你遵循此建议,还有一个附加的建议.确保在两个解决方案使用不同的命名空间。如果其中一个解决方案使用了DataLayerForAnnotations命名空间,其数据库将为

DataLayerForAnnotations.BrakeAwayContext。另一解决方案使用了

DataLayerForFluent,命名空间,其数据库将为DataLayerForFluent.BrakeAwayContext。你会看到有两个独立的数据库，很容易理解哪个解决方案影响了哪个数据库。

DbContext首先在类中查找可以获取的信息。这时，context已经准备好解析模型,但对开发者来说有一个机会来中断context和执行附加配置的连接.这得益于

DbContext.OnModelCreating方法，这是在模型创建前被上下文所调用的方法。方法是虚拟的,因此你可以覆写并加入你自已的逻辑代码.这就Fluent API进行配置的入口.

此方法的声明方式如下：

protected override void OnModelCreating(DbModelBuilder modelBuilder)

提供给OnModelCreating的参数DbModelBuilder是你需要添加配置的类。

DbModelBuilder使用泛型和lambda表达式，所以编码是强类型的可以协助您进行配置的设置。首先要告诉DbModerBuilder对哪个类(实体)实施配置:

modelBuilder.Entity<Destination>() ;

你可以配置类映射到数据库的表名:

modelBuilder.Entity<Destination>().ToTable("a_table_name");

你也可配置类的属性.如果想要配置属性,应进一步演进:

modelBuilder.Entity<Destination>()

.Property(d => d.Description).HasMaxLength(500);

代码2-10重写了前面使用data annotations建立的配置。OnModelCrating是DbContext的一个方法,请确保它在BrakAwayContext类里。

Example 2-10. Configuring with the Fluent API

protected override void OnModelCreating(DbModelBuilder modelBuilder)

{

modelBuilder.Entity<Destination>()

.Property(d => ).IsRequired();

modelBuilder.Entity<Destination>()

.Property(d => d.Description).HasMaxLength(500);

modelBuilder.Entity<Destination>()

.Property(d => d.Photo).HasColumnType("image");

modelBuilder.Entity<Lodging>()

.Property(l => ).IsRequired().HasMaxLength(200);

}

如果你疑惑HasMinLength哪里去了,在Fluent配置方法里没有最小长度的配置,因为这不会对数据库的行产生影响.

除非要配合使用Data Annotations 和 Fluent API为了保持代码一致最好选择其一。为了让代码更流畅,我们已经移除了所有的Data Annotation标记.实际上Model项目也不需要对ponent Model.DataAnnotations 或者EntityFramework程序集的引用. 再次运行代码,Code First将对比模型和数据库中的EdmMeta表,尽管我们修改了配置代码,最终结果还是一样的.同样的destination再次加入数据库中结束与匹配的记录.在图2-4你可以看到复制到的数据.

组织Fluent配置

如果你有很多配置需要执行,OnModelCreating 可能很快不堪重负(代码太多)。应该使用位于EntityTypeConfiguration的实体类来分组配置，然后在OnModelCretaing方法中告诉DbModelBuilde有些实体类r。DbModelBulider有一个Configruation属性可以来增加EntityTypeConfigurations(实体类型配置).

例2-111展示了对Destinaton类和Lodging类的分组情况:

Example 2-11. Organizing configs into separate EntityTypeConfiguration classes

using System.Data.Entity.ModelConfiguration;

using Model;

public class DestinationConfiguration :

EntityTypeConfiguration<Destination>

{

public DestinationConfiguration()

{

Property(d => ).IsRequired();

Property(d =>

.Description).HasMaxLength(500);

Property(d => d.Photo).HasColumnType("image");

}

}

public class LodgingConfiguration :

EntityTypeConfiguration<Lodging>

{

public LodgingConfiguration()

{

Property(l => ).IsRequired().HasMaxLength(200);

}

}

这些代码在OnModelCreating方 …… 此处隐藏：3618字，全部文档内容请下载后查看。喜欢就下载吧 ……