首先谈谈自己对EF的接触的过程吧，最先接触EF只是因为EF支持从数据库把关系扒下来，可以省掉自己写Select、Update、Insert这些SQL语句，而且修改非常方便，后来在使用的过程中发现导航属性这个关系，然后才慢慢知道数据库的索引是什么，由于自己接管的是大学生社团的数据库，大多时候创建者并不会考虑表的联系，一般创个主键就完事了（顺便吐槽一句，握草，数据库的表名和列名是什么鬼全用拼音首字母，为了兼容前面的内容我们还得花一半时间猜你们的列名，简直醉了，除了ID这个英文他们会，你们的英语是体育老师教的吗？？？）言归正传，用EF的确学到了对数据库表的的建立的理解，毕竟自己刚学数据库的时候就是把所有的字段塞到一张表里面，刚开始自己使用EF从数据库拔下来的表然后修改实体的关系的数据（感觉其实就是使用EF的EMDX的Code First），使用这个并没有出现很多问题，后来又接触完整的Code First，就是直接用代码生成数据库，虽然中间遇到无数的BUG但是这些BUG让我对数据库和EF的关系有了更深的理解，话不多说，直接上BUG。
1. EF未能确定外键，请用注解属性或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表中添加一个外键。也就是在这种情况里面有四种可能的情况
- 在Person表里面添加一个外键（假设为Person_SexInfoID)
- 将Person表中的ID设为主键和外键
- 在SexInfo表中添加一个外键（假设为SexInfo_PersonID)
- 将SexInfo表中的ID设为主键和外键。
注假设在EF中没有给属性添加[Key]注解属性或在Fluent API中声明一个属性为主键的话，EF会自动将有ID后缀的属性设置为主键并让他为标志字段自增，还有表中没有主键无法导入到EF中。
虽然EF有自动检测代码生成关系，但是本人还是比较推崇自己在Code First时就想好外键，这样在用模型绑定的时候就不会发生一些很可能发生的错误。在这张表里面为了节约数据库空间最好在SexInfo里面添加一个外键，现在我就来谈谈分别在两个表里面添加外键可能会遇到的BUG。
- 在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().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”。
这个错误一般出现在自己声明外键的时候，网上的资料介绍的不多，外国资料上我看过好像有人说是因为EF不允许自己声明外键，我差点就相信了····，这个BUG告诉我们依赖关系中不能为null，但是什么是依赖关系和委托关系，其实这个告诉我们的是两种关系，一种是（从属关系）Dependent Role另一种是（主体关系）Principal Role，这两种关系就是上面我们提到的外键可不可以为空，由于我们给person或PersonID没有加上Required 属性，EF系统给我们外键套上的是可空的字段，但是我们给的外键PersonID是int型，int是值类型，在C#里面值类型不能为空（如果没有初始化时为0），所以EF报错，你要么给外键加上Required标记指定它必须存在，要么给一个可为空的int型，像这个示例里面外键PersonID是必须的，然后有些对应是0-1 对 1，所以这时候就疑惑了我们怎么给外键赋值，我们有一种办法命名一种类型他的值可以int也可以为空，但是EF会认识我们这种独特的外键吗？还好EF早想到了这点，有一种泛型可以为空也可以为你想要的类型，这种就是Nullable<T> ,在这个方法中我们只要将外键PersonID的类型换成 这个
public Nullable PersonID{get;set;} 这就是解决0-1对1的方法，我们在设计数据库结构时要考虑到C#自己本身与数据库类型的对应，C#是一种强类型语言，如果我们不注意这点，程序就会崩溃。当然EF导航属性并不仅仅是1对1，还有1对多和多对多，当我们想用0去对应的话，这个外键的类型就要考虑考虑了。
还有一个比较常见的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型，