【EF Core 】DbSet与DbContext数据更新奥秘
转载：https://www.cnblogs.com/tangge/p/4528102.html
EF中的上下文（DbContext）简介
DbContext是实体类和数据库之间的桥梁， DbContext主要负责与数据交互，主要作用：
1、DbContext包含所有的实体映射到数据库表的实体集(DbSet < TEntity >)。
2、DbContext 将LINQ-to-Entities查询转换为SQL查询并将其发送到数据库。
3、更改跟踪: 它跟踪每个实体从数据库中查询出来后发生的修改变化。
4、持久化数据: 它也基于实体状态执行插入、更新和删除操作到数据库中。
功能简介
EF Core 6.0底层是Miscrosoft.Data.sqlite。DbContext，这个类是EF Code First的核心，在高层次上是数据库抽象
介绍DbSet与DbContext中的核心属性及重要方法。
DbSet:负责实体的CRUD,DbSet保留对DbContext的引用_context，并使用它来添加或删除实体。DbSet内部有一个Local 数据集，他是数据模型的本地缓存，Local属性为什么这么设计呢？照理说状态为Deleted的实体同样应该是本地缓存的啊！读者可能会发现，Local属性返回的数据类型是ObservableCollection<T>。我们知道ObservableCollection<T>常被用于WPF数据绑定。其实Local属性的设计也是为了方便大家做数据绑定的。试想在数据绑定时，如果被我们删除的实体仍然出现在Local属性的集合中，UI控件则会仍然显示这些已被我们标记为Deleted的实体。反之对于新增的实体（但还没有将更新提交到数据库），我们当然希望在做数据绑定时，UI控件也能显示它们的信息。再为大家介绍一些背景知识：过去我们如果直接把控件绑定到EF的ObjectSet<T>集合上，如果我们删除某些实体（并未提交数据库），UI控件会有相应的反应（也删除实体）。但是当我们调用类似AddObject方法在ObjectSet<T>里新增实体时，UI控件并不会有任何变化（新增实体不出现在控件）。个人觉得这是之前EF设计上的一些缺陷。
DbContext:负责跟踪实体的数据状态，并且将DBSet的crud转化成sql再数据库中执行。
DbContext是域或实体类与数据库之间的桥梁。
功能：
查询：将LINQ-to-Entities查询转换为SQL查询并将其发送到数据库。
更改跟踪：跟踪实体在从数据库查询后发生的更改。
持久化数据：根据实体的状态对数据库执行插入，更新和删除操作。
缓存：默认提供一级缓存。它存储在上下文类生命周期中已经被检索的实体。
管理关系：在Db-First或Model-First方法中使用CSDL，MSL和SSDL管理关系，并以Code-First方法使用流畅的API配置。
对象实现：将来自数据库的原始数据转换为实体对象。
DbContext类的方法：
Entry:获取DbEntityEntry给定的实体。该条目提供访问更改实体的跟踪信息和操作。
SavaChange:对已添加，已修改或已删除状态的实体的数据库执行INSERT，UPDATE或DELETE命令。
SaveChangesAsync: SaveChanges（）的异步方法
Set: 创建一个DbSet可以用来查询和保存实例的TEntity。
OnModelCreating 重写此方法以进一步配置通过DbSet派生上下文中属性中公开的实体类型按惯例发现的模型。
DbSet：表示可用于创建，读取，更新和删除操作的实体集。
DbSet 常用的方法：
Add：将给定的实体添加到添加状态的上下文中。当保存更改时，添加状态中的实体将被插入到数据库中。保存更改后，对象状态将更改为“未更改”。
Remove：将给定的实体标记为已删除。保存更改后，实体将从数据库中删除。在调用此方法之前，实体必须存在于其他某个状态的上下文中。
内部机理
这一讲极为重要，因为它揭示出了Entity Framework实现数据更新的内部机理，了解这些内容，对于用好Entity Framework非常重要。
介绍DbSet与DbContext中的核心属性及重要方法。
5.6.5 《数据更新的奥秘》
这一讲极为重要，因为它揭示出了Entity Framework实现数据更新的内部机理，了解这些内容，对于用好Entity Framework非常重要。
Entity Framework的三种开发风格
- Database First:这是一种用于已存在数据库模式的方法。使用这种方法，EDM是从数据库模式中生成的，这种方法最适合于使用了已经存在的数据库的应用。
- Code First:这种方法中，所有的领域模型都是以类的形式编写的。这些类会建立我们的EDM，数据库模式会从这些类中创建。这种方法最适合于那些高度以领域为中心并且领域模型类创建优先的应用程序。这里需要的数据库只是为了这些领域模型的持久化机制。
- Model First:这种方法和Code First方法很相似，但是这种情况下我们使用了EDM视觉设计器来设计我们的模型。数据库模式和类将会通过这个概念模型生成。该模型将会给我们创建数据库的SQL语句，然后我们可以使用它来创建数据库并连接应用程序。
三种风格的比较
Database First
主要的好处就是：如果数据库已经存在了，那么只需要花一点时间就可以编写数据访问层。EDM可以从数据库中生成，然后根据需求更改EDM。
一些场景：
- 对遗留的数据库进行开发
- 当其他团队的DBA完成了数据库设计时，一旦数据库完成，应用开发就要开始
- 当要开发数据为中心的应用时，应用领域模型就是数据库本身，数据库会频繁修改来满足新的需求。
Model First
和Database First相似，Model First最终以EDM结束。使用该EDM,我们可以创建概念模型和数据库。使用这种方法的唯一原因就是我们真的想要使用视觉实体设计器。
Code First
Code First对于所有的业务逻辑以类实现，并且数据库只用作这些模型的持久化机制时很有用。
选择Code First的一些原因：
- 数据库只是作为模型的持久化机制，即数据库中没有逻辑。
- 完全控制代码，即没有自动生成的模型和上下文代码。
- 数据库不会手动更改。模型类总是更改，然后数据库基于模型类的更改而更改。
