Entity Framework 关系约束配置

前言

简单的说一下自己的理解,大家应该都很明白ADO.NET,也就是原生态的数据库操作,直接通过拼接SQL语句,表与表之间通过链接(inner join  left join  或者子查询),也就是在设计表的时候预先设计好的,通过主外键进行关联。那么现在在Entity Framework中是如何配置处理的呢?

Entity Framework 关系约束配置

 对于实体关系对应的数据表关系,无非“0:1,1:1,1:N,N:N”这几种,可以使用导航属性中的数据类型来表示,0…1端使用单实体类型表示,N端使用ICollection集合类型表示。对于单实体端,默认是可为空的,即为0关系,如果要设置为1关系,要使用[Required]标签来进行标记。但对于一对一中的关系主体与依赖对象确无法做更细节的控制。

下面来依依看一下这几种数据表的关系

第一种:0:1。举例说明:有一个数据表Emplyee代表该公司的员工表,而该公司里的员工有一个通讯账号数据库表MessagingAccount,而有些员工不使用,也就是没有通讯账号。这就说明员工Employee和MessagingAccount之间的关系就是一个员工对应一个通讯账号,或者一个员工没有通讯账号。

WithOptional:将关系配置为required:optional。(required:0…1端的1,表示必需,不可为null;optional:0…1端的0,表示可选,可为null。下同)


modelBuilder.Entity<MessagingAccount>().HasRequired(m => m.Employee).WithOptional(n=>n.Acount);

配置一对〇关系,允许存在一个Employee而不存在MessagingAcount的情况(注意在Employee中添加Accout属性) 

第二种:1:1.举例说明:还是第一种的例子中每个员工都有一个通讯账号的话。

WithRequiredDependent:将关系配置为required:required。要配置的实体类型将成为依赖对象,且包含主体的外键。作为关系目标的实体类型将成为关系中的主体。

modelBuilder.Entity<Employee>().HasRequired(emp => emp.Acount).WithRequiredPrincipal(a => a.Employee);

 第三种:1:N。举例说明:订单和谁下的订单。通常的关系都是一个订单只会由一个人来下,反过来也就是说一个人可能有多个订单。也就是一个Customer可以有多个Order.是一个一对多的关系。

modelBuilder.Entity<Order>().HasRequired(o=>o.Customer).WithMany();

第四种:N:N。举例说明:订单和产品之间的关系。一个Order订单可能会有多个产品Product的可能。同理,一个产品Product也会存在与多个订单Order当中。

            modelBuilder.Entity<Order>().HasMany(o => o.Products).WithMany(p => p.Orders).Map(m =>
            {
                m.ToTable("OrderDetails");
                m.MapLeftKey("OrderID");
                m.MapRightKey("ProductID");
            });

配置多对多的关系,并指定了表名、对应的外键;注意如果不使用FluentAPI配置,Product和Order配置了相应的导航属性,EF也会默认生成一张表(表名为“<数据类1>+<数据类2>”)

Map:将关系配置为使用未在对象模型中公开的外键属性。可通过指定配置操作来自定义列和表。如果指定了空的配置操作,则约定将生成列名。如果在对象模型中公开了外键属性,则使用 HasForeignKey 方法。并非所有关系都支持在对象模型中公开外键属性。

特殊的一种:组合主键的使用。

  //组合主键
modelBuilder.Entity<Order>().HasRequired(o => o.Customer).WithMany().HasForeignKey(o => new { o.CustomerNo,o.CustomerName});

 复杂类型的使用。

modelBuilder.ComplexType<Name>().Property(m => m.FirstName).HasMaxLength(40);

 

posted @ 2013-09-25 22:32 aehyok 阅读(...) 评论(...) 编辑 收藏