Entity Framework 实体框架的形成之旅--Code First模式中使用 Fluent API 配置(6)

在前面的随笔《Entity Framework 实体框架的形成之旅--Code First的框架设计(5)》里介绍了基于Code First模式的实体框架的经验,这种方式自动处理出来的模式是通过在实体类(POCO类)里面添加相应的特性说明来实现的,但是有时候我们可能需要考虑基于多种数据库的方式,那这种方式可能就不合适。本篇主要介绍使用 Fluent API 配置实现Code First模式的实体框架构造方式。
使用实体框架 Code First 时,默认行为是使用一组 EF 中内嵌的约定将 POCO 类映射到表。但是,有时您无法或不想遵守这些约定,需要将实体映射到约定指示外的其他对象。特别是这些内嵌的约定可能和数据库相关的,对不同的数据库可能有不同的表示方式,或者我们可能不同数据库的表名、字段名有所不同;还有就是我们希望尽可能保持POCO类的纯洁度,不希望弄得太过乌烟瘴气的,那么我们这时候引入Fluent API 配置就很及时和必要了。

1、Code First模式的代码回顾

上篇随笔里面我构造了几个代表性的表结构,具体关系如下所示。

这些表包含了几个经典的关系,一个是自引用关系的Role表,一个是User和Role表的多对多关系,一个是User和UserDetail之间的引用关系。
我们看到,默认使用EF工具自动生成的实体类代码如下所示。

[Table("Role")]
public partial class Role
{
    public Role()
    {
        Children = new HashSet<Role>();
        Users = new HashSet<User>();
    }

    [StringLength(50)]
    public string ID { get; set; }

    [StringLength(50)]
    public string Name { get; set; }

    [StringLength(50)]
    public string ParentID { get; set; }

    public virtual ICollection<Role> Children { get; set; }

    public virtual Role Parent { get; set; }

    public virtual ICollection<User> Users { get; set; }
}

而其生成的数据库操作上下文类的代码如下所示。

public partial class DbEntities : DbContext
{
    public DbEntities() : base("name=Model1")
    {
    }
    public virtual DbSet<Role> Roles { get; set; }
    public virtual DbSet<User> Users { get; set; }
    public virtual DbSet<UserDetail> UserDetails { get; set; }

    protected override void OnModelCreating(DbModelBuilder modelBuilder)
    {
        modelBuilder.Entity<Role>()
            .HasMany(e => e.Children)
            .WithOptional(e => e.Parent)
            .HasForeignKey(e => e.ParentID);

        modelBuilder.Entity<Role>()
            .HasMany(e => e.Users)
            .WithMany(e => e.Roles)
            .Map(m => m.ToTable("UserRole"));

        modelBuilder.Entity<User>()
            .HasMany(e => e.UserDetails)
            .WithOptional(e => e.User)
            .HasForeignKey(e => e.User_ID);

        modelBuilder.Entity<UserDetail>()
            .Property(e => e.Height)
            .HasPrecision(18, 0);
    }
}

2、使用Fluent API 配置的Code First模式代码结构

不管是Code First模式中使用 Fluent API 配置,还是使用了前面的Attribute特性标记的说明,都是为了从代码层面上构建实体类和表之间的信息,或者多个表之间一些关系,不过如果我们把这些实体类Attribute特性标记去掉的话,那么我们就可以通过Fluent API 配置进行属性和关系的指定了。

其实前面的OnModelCreating函数里面,已经使用了这种方式来配置表之间的关系了,为了纯粹使用Fluent API 配置,我们还需要把实体类进行简化,最终我们可以获得真正的实体类信息如下所示。

public partial class User
{
    public User()
    {
        UserDetails = new HashSet<UserDetail>();
        Roles = new HashSet<Role>();
    }

    public string ID { get; set; }

    public string Account { get; set; }

    public string Password { get; set; }

    public virtual ICollection<UserDetail> UserDetails { get; set; }

    public virtual ICollection<Role> Roles { get; set; }
}

这个实体类和我们以往的表现几乎一样,没有多余的信息,唯一多的就是完全是实体对象化了,包括了一些额外的关联对象信息。
前面说了,Oracle的生成实体类字段全部为大写字母,不过我们实体类还是需要保持它的Pascal模式书写格式,那么就可以在Fluent API 配置进行指定它的字段名为大写(注意,Oracle一定要指定字段名为大写,因为它是大小写敏感的)。
最终我们定义了Oracle数据库USERS表对应映射关系如下所示。

/// <summary>
/// 用户表USERS的映射信息(Fluent API 配置)
/// </summary>
public class UserMap : EntityTypeConfiguration<User>  
{
    public UserMap()
    {
        HasMany(e => e.UserDetails).WithOptional(e => e.User).HasForeignKey(e => e.User_ID);
        
        Property(t => t.ID).HasColumnName("ID");
        Property(t => t.Account).HasColumnName("ACCOUNT");
        Property(t => t.Password).HasColumnName("PASSWORD");

        ToTable("WHC.USERS");
    }
}

我们为每一个字段进行了字段名称的映射,而且Oracle要大写,我们还通过 ToTable("WHC.USERS") 把它映射到了WHC.USERS表里面了。
如果对于有多对多中间表关系的Role来说,我们看看它的关系代码如下所示。

/// <summary>
/// 用户表 ROLE 的映射信息(Fluent API 配置)
/// </summary>
public class RoleMap : EntityTypeConfiguration<Role>  
{
    public RoleMap()
    {
        Property(t => t.ID).HasColumnName("ID");
        Property(t => t.Name).HasColumnName("NAME");
        Property(t => t.ParentID).HasColumnName("PARENTID");
        ToTable("WHC.ROLE");
        
        HasMany(e => e.Children).WithOptional(e => e.Parent).HasForeignKey(e => e.ParentID);
        HasMany(e => e.Users).WithMany(e => e.Roles).Map(m=>
            {
                m.MapLeftKey("ROLE_ID");
                m.MapRightKey("USER_ID");
                m.ToTable("USERROLE", "WHC");
            });
    }
}

这里注意的是MapLeftKey和MapRightKey一定的对应好了,否则会有错误的问题,一般情况下,开始可能很难理解那个是Left,那个是Right,不过经过测试,可以发现Left的肯定是指向当前的这个映射实体的键(如上面的为ROLE_ID这个是Left一样,因为当前的实体映射是Role对象)。

通过这些映射代码的建立,我们为每个表都建立了一一的对应关系,剩下来的就是把这映射关系加载到数据库上下文对象里面了,还记得刚才说到的OnModelCreating吗,就是那里,一般我们加载的方式如下所示。

//手工加载
modelBuilder.Configurations.Add(new UserMap());
modelBuilder.Configurations.Add(new RoleMap());
modelBuilder.Configurations.Add(new UserDetailMap()); 

这种做法代替了原来的臃肿代码方式。

modelBuilder.Entity<Role>()
    .HasMany(e => e.Children)
    .WithOptional(e => e.Parent)
    .HasForeignKey(e => e.ParentID);

modelBuilder.Entity<Role>()
    .HasMany(e => e.Users)
    .WithMany(e => e.Roles)
    .Map(m => m.ToTable("UserRole"));

modelBuilder.Entity<User>()
    .HasMany(e => e.UserDetails)
    .WithOptional(e => e.User)
    .HasForeignKey(e => e.User_ID);

modelBuilder.Entity<UserDetail>()
    .Property(e => e.Height)
    .HasPrecision(18, 0);

一般情况下,到这里我认为基本上把整个思路已经介绍完毕了,不过精益求精一贯是个好事,对于上面的代码我还是觉得不够好,因为我每次在加载 Fluent API 配置的时候,都需要指定具体的映射类,非常不好,如果能够把它们动态加载进去,岂不妙哉。

对类似下面的关系硬编码可不是一件好事。

modelBuilder.Configurations.Add(new UserMap());
modelBuilder.Configurations.Add(new RoleMap());
modelBuilder.Configurations.Add(new UserDetailMap()); 

我们可以通过反射方式,把它们进行动态的加载即可。这样OnModelCreating函数处理的时候,就是很灵活的了,而且OnModelCreating函数只是在程序启动的时候映射一次而已,即使重复构建数据库操作上下文对象DbEntities的时候,也是不会重复触发这个OnModelCreating函数的,因此我们利用反射不会有后顾之忧,性能只是第一次慢一点而已,后面都不会重复触发了。

最终我们看看一步步下来的代码如下所示(注释的代码是不再使用的代码)。

protected override void OnModelCreating(DbModelBuilder modelBuilder)
{
    #region MyRegion
    //modelBuilder.Entity<Role>()
    //    .HasMany(e => e.Children)
    //    .WithOptional(e => e.Parent)
    //    .HasForeignKey(e => e.ParentID);

    //modelBuilder.Entity<Role>()
    //    .HasMany(e => e.Users)
    //    .WithMany(e => e.Roles)
    //    .Map(m => m.ToTable("UserRole"));

    //modelBuilder.Entity<User>()
    //    .HasMany(e => e.UserDetails)
    //    .WithOptional(e => e.User)
    //    .HasForeignKey(e => e.User_ID);

    //modelBuilder.Entity<UserDetail>()
    //    .Property(e => e.Height)
    //    .HasPrecision(18, 0);

    //手工加载
    //modelBuilder.Configurations.Add(new UserMap());
    //modelBuilder.Configurations.Add(new RoleMap());
    //modelBuilder.Configurations.Add(new UserDetailMap()); 
    #endregion

    //使用数据库后缀命名,确保加载指定的数据库映射内容
    //string mapSuffix = ".Oracle";//.SqlServer/.Oracle/.MySql/.SQLite
    string mapSuffix = ConvertProviderNameToSuffix(defaultConnectStr.ProviderName);
    
    var typesToRegister = Assembly.GetExecutingAssembly().GetTypes()
        .Where(type => type.Namespace.EndsWith(mapSuffix, StringComparison.OrdinalIgnoreCase))
        .Where(type => !String.IsNullOrEmpty(type.Namespace))
        .Where(type => type.BaseType != null && type.BaseType.IsGenericType
            && type.BaseType.GetGenericTypeDefinition() == typeof(EntityTypeConfiguration<>));

    foreach (var type in typesToRegister)
    {
        dynamic configurationInstance = Activator.CreateInstance(type);
        modelBuilder.Configurations.Add(configurationInstance);
    }
    base.OnModelCreating(modelBuilder); 
}

这样我们运行程序运行正常,不在受约束于实体类的字段必须是大写的忧虑了。而且动态加载,对于我们使用其他数据库,依旧是个好事,因为其他数据库也只需要修改一下映射就可以了,真正远离了复杂的XML和实体类臃肿的Attribute书写内容,实现了非常弹性化的映射处理了。

最后我贴出一下测试的代码例子,和前面的随笔使用没有太大的差异。

private void button1_Click(object sender, EventArgs e)
{
    DbEntities db = new DbEntities();

    User user = new User();
    user.Account = "TestName" + DateTime.Now.ToShortTimeString();
    user.ID = Guid.NewGuid().ToString();
    user.Password = "Test";

    UserDetail detail = new UserDetail() { ID = Guid.NewGuid().ToString(), Name = "userName33", Sex = 1, Note = "测试内容33", Height = 175 };
    user.UserDetails.Add(detail);
    db.Users.Add(user);

    Role role = new Role();
    role.ID = Guid.NewGuid().ToString();
    role.Name = "TestRole";
    //role.Users.Add(user);

    user.Roles.Add(role);
    db.Users.Add(user);
    //db.Roles.Add(role);
    db.SaveChanges();

    Role roleInfo = db.Roles.FirstOrDefault();
    if (roleInfo != null)
    {
        Console.WriteLine(roleInfo.Name);
        if (roleInfo.Users.Count > 0)
        {
            Console.WriteLine(roleInfo.Users.ToList()[0].Account);
        }
        MessageBox.Show("OK");
    }
}

测试Oracle数据库,我们可以发现数据添加到数据库里面了。



而且上面例子也创建了总结表的对应关系,具体数据如下所示。


如果是SQLServer,我们还可以看到数据库里面添加了一个额外的表,如下所示。



如果表的相关信息变化了,记得把这个表里面的记录清理一下,否则会出现一些错误提示,如果去找代码,可能会发现浪费很多时间都没有很好定位到具体的问题的。
这个表信息,在其它数据库里面没有发现,如Oracle、Mysql、Sqlite里面都没有,SQLServer这个表的具体数据如下所示。



整个项目的结构优化为标准的框架结构后,结构层次如下所示。
最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 203,271评论 5 476
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 85,275评论 2 380
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 150,151评论 0 336
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,550评论 1 273
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,553评论 5 365
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,559评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,924评论 3 395
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,580评论 0 257
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,826评论 1 297
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,578评论 2 320
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,661评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,363评论 4 318
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,940评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,926评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,156评论 1 259
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 42,872评论 2 349
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,391评论 2 342

推荐阅读更多精彩内容