Contents
  1. 1. 首先谈谈自己对EF的接触的过程吧,最先接触EF只是因为EF支持从数据库把关系扒下来,可以省掉自己写Select、Update、Insert这些SQL语句,而且修改非常方便,后来在使用的过程中发现导航属性这个关系,然后才慢慢知道数据库的索引是什么,由于自己接管的是大学生社团的数据库,大多时候创建者并不会考虑表的联系,一般创个主键就完事了(顺便吐槽一句,握草,数据库的表名和列名是什么鬼全用拼音首字母,为了兼容前面的内容我们还得花一半时间猜你们的列名,简直醉了,除了ID这个英文他们会,你们的英语是体育老师教的吗???)言归正传,用EF的确学到了对数据库表的的建立的理解,毕竟自己刚学数据库的时候就是把所有的字段塞到一张表里面,刚开始自己使用EF从数据库拔下来的表然后修改实体的关系的数据(感觉其实就是使用EF的EMDX的Code First),使用这个并没有出现很多问题,后来又接触完整的Code First,就是直接用代码生成数据库,虽然中间遇到无数的BUG但是这些BUG让我对数据库和EF的关系有了更深的理解,话不多说,直接上BUG。
  • 1. EF未能确定外键,请用注解属性或Fluent API标记外键
    1. 1. 首先ID是独一无二的,而Name不是(重名的有很多),当我们给ID套上主键的时候,这时候插入这张表的ID只能有一种(这是数据库的一种约束,当然你可以不选择这种约束),一个人除了姓名还有其他东西,假如这时我们还有帮他加入性别这个信息,我们可以修改上一张表添加一个字段,也可以新建一张表存贮性别这个信息(当然在实际生活中只用一张表存一个信息很少),我们新建的这张表是这样的,
      1. 1.0.1. ps:说到外键不能为空我插一句,有些教科书上说外键不能为空也是对的,外键只是一个列名,当这个列名不唯一(也就是不为主键的时候)这是外键可以为空,为空的含义是不确定对应主表的值。
      2. 1.0.2. 注假设在EF中没有给属性添加[Key]注解属性或在Fluent API中声明一个属性为主键的话,EF会自动将有ID后缀的属性设置为主键并让他为标志字段自增,还有表中没有主键无法导入到EF中。
  • 2. BUG:模型验证错误····多重性与关系“········”中 Role“··············”中的引用约束冲突。因为 Dependent Role 中的所有属性都不可以为 null,Principal Role 的多重性必须为“1”。
  • 里面值类型不能为空(如果没有初始化时为0),所以EF报错,你要么给外键加上Required标记指定它必须存在,要么给一个可为空的int型,像这个示例里面外键PersonID是必须的,然后有些对应是0-1 对 1,所以这时候就疑惑了我们怎么给外键赋值,我们有一种办法命名一种类型他的值可以int也可以为空,但是EF会认识我们这种独特的外键吗?还好EF早想到了这点,有一种泛型可以为空也可以为你想要的类型,这种就是Nullable ,在这个方法中我们只要将外键PersonID的类型换成 这个
  • 自己本身与数据库类型的对应,C
    1. 1. BUG:······: 引用约束的 Dependent Role 中所有属性的类型都必须与 Principal Role 中相应的属性类型相同。引用约束“·····”中,实体“····”的属性“····”的类型与实体“·····”的属性“·····”的类型不匹配。
    2. 2. ps:导航属性是指对象,比如说Person类实例person,而外键是指存贮在数据库里面的一个特殊的列名。
  • 充分认识导航属性和外键是搭建一个扎实的数据库结构的基础,在学习和应用EF的过程中也是了解数据库的结构的学习过程,EF或许在运行速度方法上比一般的SQL语句要慢,但是用EF我们可以更加方便的搭建一个好的数据体系,搭建一个好的数据体系可以让你在完成项目的时候事半功倍。
  • 首先谈谈自己对EF的接触的过程吧,最先接触EF只是因为EF支持从数据库把关系扒下来,可以省掉自己写Select、Update、Insert这些SQL语句,而且修改非常方便,后来在使用的过程中发现导航属性这个关系,然后才慢慢知道数据库的索引是什么,由于自己接管的是大学生社团的数据库,大多时候创建者并不会考虑表的联系,一般创个主键就完事了(顺便吐槽一句,握草,数据库的表名和列名是什么鬼全用拼音首字母,为了兼容前面的内容我们还得花一半时间猜你们的列名,简直醉了,除了ID这个英文他们会,你们的英语是体育老师教的吗???)言归正传,用EF的确学到了对数据库表的的建立的理解,毕竟自己刚学数据库的时候就是把所有的字段塞到一张表里面,刚开始自己使用EF从数据库拔下来的表然后修改实体的关系的数据(感觉其实就是使用EF的EMDX的Code First),使用这个并没有出现很多问题,后来又接触完整的Code First,就是直接用代码生成数据库,虽然中间遇到无数的BUG但是这些BUG让我对数据库和EF的关系有了更深的理解,话不多说,直接上BUG。


    1. EF未能确定外键,请用注解属性或Fluent API标记外键

    网上关于如何用代码的(Fluent API或注解属性)指定外键的文章有很多有很多。在这里我想谈谈对外键的理解,首先建立起一张主表


    主表














    列名

    类型

    ID

    int

    Name

    nvarchar(50)

    首先ID是独一无二的,而Name不是(重名的有很多),当我们给ID套上主键的时候,这时候插入这张表的ID只能有一种(这是数据库的一种约束,当然你可以不选择这种约束),一个人除了姓名还有其他东西,假如这时我们还有帮他加入性别这个信息,我们可以修改上一张表添加一个字段,也可以新建一张表存贮性别这个信息(当然在实际生活中只用一张表存一个信息很少),我们新建的这张表是这样的,


    附表










    列名

    类型

    Sex

    bit

    这张表存贮了性别这个信息,但是如何将他从主表联系起来呢,我们先提取主表中的ID作为联系(我们称为外键)表改为


    附表














    列名

    类型

    ID

    int

    Sex

    bit

    我们把列名ID设为主键,这样我们就建立了一对一的关系,这个附表的ID必须不为空,这种关系还有一种就是将外键存贮在主表里面,就是将主表里面添加一个外键SexID,主表和附表要改成下面这种


    主表




















    列名

    类型

    ID

    int

    Name

    nvarchar(50)

    SexID

    int

    附表










    列名

    类型

    Sex

    bit

    现在这种结构就是外键SexID可以为空(注上面的外键不能为空),

    ps:说到外键不能为空我插一句,有些教科书上说外键不能为空也是对的,外键只是一个列名,当这个列名不唯一(也就是不为主键的时候)这是外键可以为空,为空的含义是不确定对应主表的值。

    现在开始谈谈这种情况在EF发生的原因,你吧主表设为Person表,附表为SexInfo表,对应的代码如下

    public Person{
        public int ID{get;set;}
        public string name{get;set;}
        public virtual SexInfo Sex{get;set;
                                                }
    
    
    public SexInfo{
        public int ID{get;set;
        public bool Sex{get;set;
        public Person person{get;set;}
                                }
    

    这个时候EF无法判断哪个是主表那个是附表,就是无法将外键加在哪个表的ID上,或者像上面的表中在Person表中添加一个外键。也就是在这种情况里面有四种可能的情况

    1. 在Person表里面添加一个外键(假设为Person_SexInfoID)
    2. 将Person表中的ID设为主键和外键
    3. 在SexInfo表中添加一个外键(假设为SexInfo_PersonID)
    4. 将SexInfo表中的ID设为主键和外键。
    注假设在EF中没有给属性添加[Key]注解属性或在Fluent API中声明一个属性为主键的话,EF会自动将有ID后缀的属性设置为主键并让他为标志字段自增,还有表中没有主键无法导入到EF中。

    虽然EF有自动检测代码生成关系,但是本人还是比较推崇自己在Code First时就想好外键,这样在用模型绑定的时候就不会发生一些很可能发生的错误。在这张表里面为了节约数据库空间最好在SexInfo里面添加一个外键,现在我就来谈谈分别在两个表里面添加外键可能会遇到的BUG。

    1. 在SexInfo里面添加外键PersonID

    类修改成为

    public Person{
        public int ID{get;set;}
        public string name{get;set;}
        public virtual SexInfo Sex{get;set;
                                                }
    
    
    public SexInfo{
        public int ID{get;set;
        public bool Sex{get;set;
        public int PersonID{get;set;}
        public Person person{get;set;}
                                }
    

    然后我们可以选择在PersonID上加上[ForeignKey("Person")][Requird],或者在重写的OnModelCreating方法中加入 这样一句代码

    modelBuilder.Entity<SexInfo>().HasRequired(x => x.Person)
    .WithRequiredPrincipal(x => x.BindingRole).HasForeignKey(x => x.MenusManageID)        
    

    其实我更推崇写Fluent API 来约束,因为将注解属性放在Model里面太乱而且容易错,比如说假如你在PersonID上面少注释了一个[Required] 你又会得到一个模型验证错误,这个BUG是隐藏的最深的,现在来重点提一提这个BUG

    BUG:模型验证错误····多重性与关系“········”中 Role“··············”中的引用约束冲突。因为 Dependent Role 中的所有属性都不可以为 null,Principal Role 的多重性必须为“1”。

    里面值类型不能为空(如果没有初始化时为0),所以EF报错,你要么给外键加上Required标记指定它必须存在,要么给一个可为空的int型,像这个示例里面外键PersonID是必须的,然后有些对应是0-1 对 1,所以这时候就疑惑了我们怎么给外键赋值,我们有一种办法命名一种类型他的值可以int也可以为空,但是EF会认识我们这种独特的外键吗?还好EF早想到了这点,有一种泛型可以为空也可以为你想要的类型,这种就是Nullable<T> ,在这个方法中我们只要将外键PersonID的类型换成 这个

    public Nullable<int> PersonID{get;set;}
    

    自己本身与数据库类型的对应,C

    还有一个比较常见的BUG吧,来提一提。

    BUG:······: 引用约束的 Dependent Role 中所有属性的类型都必须与 Principal Role 中相应的属性类型相同。引用约束“·····”中,实体“····”的属性“····”的类型与实体“·····”的属性“·····”的类型不匹配。

    这个bug就是相对应主体和外键不匹配的情况,相对应的类如下

        public Person{
        public long ID{get;set;}
        public string name{get;set;}
        public virtual SexInfo Sex{get;set;
                                                }
    
    
    public SexInfo{
        public int ID{get;set;
        public bool Sex{get;set;
        public int PersonID{get;set;}
        public Person person{get;set;}
                                }
    

    Person里面的主键我改成了long型,然而外键PersonID却是int型,出现这个错误是对外键的认识还不够,外键其实就是主键的“分身”,主键是long型,外键必须也是long型,同理主键是int型外键也必须是ing型,

    ps:导航属性是指对象,比如说Person类实例person,而外键是指存贮在数据库里面的一个特殊的列名。


    充分认识导航属性和外键是搭建一个扎实的数据库结构的基础,在学习和应用EF的过程中也是了解数据库的结构的学习过程,EF或许在运行速度方法上比一般的SQL语句要慢,但是用EF我们可以更加方便的搭建一个好的数据体系,搭建一个好的数据体系可以让你在完成项目的时候事半功倍。

    Contents
    1. 1. 首先谈谈自己对EF的接触的过程吧,最先接触EF只是因为EF支持从数据库把关系扒下来,可以省掉自己写Select、Update、Insert这些SQL语句,而且修改非常方便,后来在使用的过程中发现导航属性这个关系,然后才慢慢知道数据库的索引是什么,由于自己接管的是大学生社团的数据库,大多时候创建者并不会考虑表的联系,一般创个主键就完事了(顺便吐槽一句,握草,数据库的表名和列名是什么鬼全用拼音首字母,为了兼容前面的内容我们还得花一半时间猜你们的列名,简直醉了,除了ID这个英文他们会,你们的英语是体育老师教的吗???)言归正传,用EF的确学到了对数据库表的的建立的理解,毕竟自己刚学数据库的时候就是把所有的字段塞到一张表里面,刚开始自己使用EF从数据库拔下来的表然后修改实体的关系的数据(感觉其实就是使用EF的EMDX的Code First),使用这个并没有出现很多问题,后来又接触完整的Code First,就是直接用代码生成数据库,虽然中间遇到无数的BUG但是这些BUG让我对数据库和EF的关系有了更深的理解,话不多说,直接上BUG。
  • 1. EF未能确定外键,请用注解属性或Fluent API标记外键
    1. 1. 首先ID是独一无二的,而Name不是(重名的有很多),当我们给ID套上主键的时候,这时候插入这张表的ID只能有一种(这是数据库的一种约束,当然你可以不选择这种约束),一个人除了姓名还有其他东西,假如这时我们还有帮他加入性别这个信息,我们可以修改上一张表添加一个字段,也可以新建一张表存贮性别这个信息(当然在实际生活中只用一张表存一个信息很少),我们新建的这张表是这样的,
      1. 1.0.1. ps:说到外键不能为空我插一句,有些教科书上说外键不能为空也是对的,外键只是一个列名,当这个列名不唯一(也就是不为主键的时候)这是外键可以为空,为空的含义是不确定对应主表的值。
      2. 1.0.2. 注假设在EF中没有给属性添加[Key]注解属性或在Fluent API中声明一个属性为主键的话,EF会自动将有ID后缀的属性设置为主键并让他为标志字段自增,还有表中没有主键无法导入到EF中。
  • 2. BUG:模型验证错误····多重性与关系“········”中 Role“··············”中的引用约束冲突。因为 Dependent Role 中的所有属性都不可以为 null,Principal Role 的多重性必须为“1”。
  • 里面值类型不能为空(如果没有初始化时为0),所以EF报错,你要么给外键加上Required标记指定它必须存在,要么给一个可为空的int型,像这个示例里面外键PersonID是必须的,然后有些对应是0-1 对 1,所以这时候就疑惑了我们怎么给外键赋值,我们有一种办法命名一种类型他的值可以int也可以为空,但是EF会认识我们这种独特的外键吗?还好EF早想到了这点,有一种泛型可以为空也可以为你想要的类型,这种就是Nullable ,在这个方法中我们只要将外键PersonID的类型换成 这个
  • 自己本身与数据库类型的对应,C
    1. 1. BUG:······: 引用约束的 Dependent Role 中所有属性的类型都必须与 Principal Role 中相应的属性类型相同。引用约束“·····”中,实体“····”的属性“····”的类型与实体“·····”的属性“·····”的类型不匹配。
    2. 2. ps:导航属性是指对象,比如说Person类实例person,而外键是指存贮在数据库里面的一个特殊的列名。
  • 充分认识导航属性和外键是搭建一个扎实的数据库结构的基础,在学习和应用EF的过程中也是了解数据库的结构的学习过程,EF或许在运行速度方法上比一般的SQL语句要慢,但是用EF我们可以更加方便的搭建一个好的数据体系,搭建一个好的数据体系可以让你在完成项目的时候事半功倍。