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这个表的具体数据如下所示。

整个项目的结构优化为标准的框架结构后,结构层次如下所示。

本文转自博客园伍华聪的博客,原文链接:Entity Framework 实体框架的形成之旅--Code First模式中使用 Fluent API 配置(6),如需转载请自行联系原博主。



目录
相关文章
|
1月前
|
Java API 数据库
构建RESTful API已经成为现代Web开发的标准做法之一。Spring Boot框架因其简洁的配置、快速的启动特性及丰富的功能集而备受开发者青睐。
【10月更文挑战第11天】本文介绍如何使用Spring Boot构建在线图书管理系统的RESTful API。通过创建Spring Boot项目,定义`Book`实体类、`BookRepository`接口和`BookService`服务类,最后实现`BookController`控制器来处理HTTP请求,展示了从基础环境搭建到API测试的完整过程。
42 4
|
1月前
|
XML JSON API
ServiceStack:不仅仅是一个高性能Web API和微服务框架,更是一站式解决方案——深入解析其多协议支持及简便开发流程,带您体验前所未有的.NET开发效率革命
【10月更文挑战第9天】ServiceStack 是一个高性能的 Web API 和微服务框架,支持 JSON、XML、CSV 等多种数据格式。它简化了 .NET 应用的开发流程,提供了直观的 RESTful 服务构建方式。ServiceStack 支持高并发请求和复杂业务逻辑,安装简单,通过 NuGet 包管理器即可快速集成。示例代码展示了如何创建一个返回当前日期的简单服务,包括定义请求和响应 DTO、实现服务逻辑、配置路由和宿主。ServiceStack 还支持 WebSocket、SignalR 等实时通信协议,具备自动验证、自动过滤器等丰富功能,适合快速搭建高性能、可扩展的服务端应用。
108 3
|
6天前
|
JSON JavaScript 中间件
Koa框架下的RESTful API设计与实现
在现代 Web 开发中,构建高效、可维护的 API 是至关重要的。Koa 是一个流行的 Node.js Web 应用框架,它具有简洁、灵活和强大的特性,非常适合用于设计和实现 RESTful API。
|
12天前
|
API PHP 数据库
PHP中哪个框架最适合做API?
在数字化时代,API作为软件应用间通信的桥梁至关重要。本文探讨了PHP中适合API开发的主流框架,包括Laravel、Symfony、Lumen、Slim、Yii和Phalcon,分析了它们的特点和优势,帮助开发者选择合适的框架,提高开发效率、保证接口稳定性和安全性。
35 3
|
19天前
|
JavaScript 中间件 API
Node.js进阶:Koa框架下的RESTful API设计与实现
【10月更文挑战第28天】本文介绍了如何在Koa框架下设计与实现RESTful API。首先概述了Koa框架的特点,接着讲解了RESTful API的设计原则,包括无状态和统一接口。最后,通过一个简单的博客系统示例,详细展示了如何使用Koa和koa-router实现常见的CRUD操作,包括获取、创建、更新和删除文章。
36 4
|
11天前
|
安全 API 网络架构
Python中哪个框架最适合做API?
本文介绍了Python生态系统中几个流行的API框架,包括Flask、FastAPI、Django Rest Framework(DRF)、Falcon和Tornado。每个框架都有其独特的优势和适用场景。Flask轻量灵活,适合小型项目;FastAPI高性能且自动生成文档,适合需要高吞吐量的API;DRF功能强大,适合复杂应用;Falcon高性能低延迟,适合快速API开发;Tornado异步非阻塞,适合高并发场景。文章通过示例代码和优缺点分析,帮助开发者根据项目需求选择合适的框架。
39 0
|
1月前
|
数据采集 人工智能 自然语言处理
Python实时查询股票API的FinanceAgent框架构建股票(美股/A股/港股)AI Agent
金融领域Finance AI Agents方面的工作,发现很多行业需求和用户输入的 query都是和查询股价/行情/指数/财报汇总/金融理财建议相关。如果需要准确的 金融实时数据就不能只依赖LLM 来生成了。常规的方案包括 RAG (包括调用API )再把对应数据和prompt 一起拼接送给大模型来做文本生成。稳定的一些商业机构的金融数据API基本都是收费的,如果是以科研和demo性质有一些开放爬虫API可以使用。这里主要介绍一下 FinanceAgent,github地址 https://github.com/AI-Hub-Admin/FinanceAgent
|
2月前
|
JSON Go API
使用Go语言和Gin框架构建RESTful API:GET与POST请求示例
使用Go语言和Gin框架构建RESTful API:GET与POST请求示例
|
2月前
|
开发框架 JSON 缓存
震撼发布!Python Web开发框架下的RESTful API设计全攻略,让数据交互更自由!
在数字化浪潮推动下,RESTful API成为Web开发中不可或缺的部分。本文详细介绍了在Python环境下如何设计并实现高效、可扩展的RESTful API,涵盖框架选择、资源定义、HTTP方法应用及响应格式设计等内容,并提供了基于Flask的示例代码。此外,还讨论了版本控制、文档化、安全性和性能优化等最佳实践,帮助开发者实现更流畅的数据交互体验。
87 1
|
2月前
|
JSON 资源调度 JavaScript
Vue框架中Ajax请求的实现方式:使用axios库或fetch API
选择 `axios`还是 `fetch`取决于项目需求和个人偏好。`axios`提供了更丰富的API和更灵活的错误处理方式,适用于需要复杂请求配置的场景。而 `fetch`作为现代浏览器的原生API,使用起来更为简洁,但在旧浏览器兼容性和某些高级特性上可能略显不足。无论选择哪种方式,它们都能有效地在Vue应用中实现Ajax请求的功能。
42 4

热门文章

最新文章

下一篇
无影云桌面