EF

延迟加载与贪婪加载

EF查询默认会延迟加载
EF对于集合类型的导航属性会延迟加载
本质：IQueryable拥有3个成员，Expression，Type，Provider
IQueryable与IEnumberable对比区别：
IQueryable: 可以拼接一个完成的SQL语句，然后请求数据库，拿到需要的数据
IEnumberable:直接把第一个命令请求数据库，然后拿到数据，在内存当中对于后续条件进行筛选。
把IQueryable 转换为IEnumberable ：IQueryable.AsEnumberable();
贪婪加载（非延迟加载）就是把所有要加载的东西一 次性读取
EF非延迟加载：使用ToList()方法将结果立即拿到内存中(最好把命令全部拼接完之后使用ToList())
EF导航属性的非延迟加载：Include("") 可以使导航属性非延迟加载
EF延迟加载 优点：用时才加载数据，可以减少不必要的开销，保证数据的有效性
EF延迟加载 缺点：每次访问都加载一次，加重了数据库服务器的负担

Db first, code first, model first

• Database First是基于已存在的数据库，利用某些工具（如Vs提供的EF设计器）创建实体类，数据库对象与实体类的匹配关系等，你也可以手动修改这些自动生成的代码及匹配文件。
• Model First 这种方式是先利用某些工具（如VS的EF设计器）设计出实体数据模型及他们之间的关系，然后再根据这些实体、关系去生成数据库对象及相关代码文件。
• Code First 这种方式需要先写一些代码，如实体对象，数据关系等，然后根据已有的代码描述，自动创建数据对象，这种方式在前一篇文章已经简单说过了。但其实这种方法与Model First是非常类似的。我们自己写的代码，其实就是用代码表示实体模型，而Model First是用可视化的方式描述了实体模型。

下面分析这三种方式的优缺点：
Database-First模式明显性能会差点，但是它很适合初学者，或者是比较急的小型项目。还有一点，我们在做项目时可能不容易体会到它的好处，但如果做数据库结构比较成熟稳定的产品时，我们可以很轻松的使用数据库生成实体模型，从而实现快速开发。
Model-First模式优点是开发人员能够在模型设计完成后，可以利用VS等工具快速生成数据库脚本。缺点是设计模型时完全了解数据库的结构，在模型中手动添加表关系，并且生成的脚本有点不简洁。
Code-First模式优点是性能比较好，且代码较少冗余。不过它的缺点也有很多，由于都是代码编写的，比如更新数据库。

实体关系(one-to-one, one-to-many, many-to-many)

one-to-one 单向一对一

双向一对一

One-to-many

Many-to-many

EF框架和Ado.Net的使用比较

1、性能上（运行效率）
Ado.Net的性能更高些，直接使用SQLHelper的Command、Connection等命令通过写SQL语句对数据库进行操作。（EF的实体模型，性能上肯定要损失些！！）

2、方便性上（开发效率）
EF使用起来更方便，原因是开发人员不用关心如何访问数据库了。

3、适用性上
EF适合较大型的项目，数据量也较大些；而Ado.Net适用于小型项目（执行效率高些）。

4、灵活性上
Ado.Net灵活性更高，但可能存在sql注入的问题。
EF省去了sql注入的麻烦，使用EF，数据库切换比较方便

EF最终都是翻译转换成sql去执行的，开发很快捷。ado相对来说你可以自行处理sql存储过程和脚本，灵活性大，不需要进行翻译，但工作量会相对多一些。
微软最初退出ORM技术，目的是在提高开发效率，并不是提高运行效率，它只是使对数据库的编码更符合面向对象的编程的方式。
EF框架和Ado.Net，其实简单来说，就是封装和原生的PK了。