使用 Entity Framework 的开发方法

Entity Framework 在开发应用程序时遵循三种不同的方法。

1. 数据库优先
2. 代码优先
4. 模型优先

数据库优先方法

在数据库优先开发方法中，我们使用与 Visual Studio 集成的 EDM 向导或执行 Entity Framework 命令为现有数据库生成上下文和实体。

Entity Framework6 广泛支持数据库优先方法。

代码优先方法

当我们没有应用程序的现有数据库时，我们会使用这种方法。在代码优先方法中，我们开始编写实体和上下文类，然后使用迁移命令从这些类创建数据库。

遵循领域驱动设计原则的开发人员，在这里我们更喜欢先开始编写领域类，然后生成需要持久化数据的数据库。

模型优先方法

在模型优先方法中，我们创建实体、关系和继承层次结构。

直接在与 Visual Studio 集成的 Visual Designer 上，然后从可视模型生成实体、上下文类和数据库脚本。

EF6 对此方法的支持有限。 Entity Framework Core 不支持此方法。

为我们的应用程序选择开发方法

我们使用以下流程图来决定使用 Entity Framework 开发应用程序的正确方法。

上图显示，如果我们已经有一个带有领域类的现有应用程序，那么我们可以使用代码优先方法，因为我们可以从我们现有的类创建数据库。如果我们有一个现有的数据库，那么我们可以在数据库优先方法中从现有数据库创建 EDM。如果我们没有现有的数据库或领域类，我们将更喜欢在 Visual Designer 上设计自己的数据库模型，然后我们将选择模型优先方法。

Entity Framework 中的持久性

当使用 entity framework 将实体保存到数据库时，有两种情况，分别是连接场景和断开连接场景。

连接场景

在连接场景中，使用同一个上下文类（从 DBContext 派生）的实例来检索和保存实体。连接场景在其生命周期中跟踪所有实体。这在具有本地数据库或同一网络上数据库的 Windows 应用程序中非常有用。

以下是 Entity Framework 中连接场景的优缺点。

断开连接场景

在断开连接场景中，使用不同的上下文实例来检索和保存数据库中的实体。检索数据后，上下文的实例将被释放，并创建一个新实例来将实体保存到数据库中。

断开连接场景很复杂，因为上下文的一个实例不跟踪实体，因此我们需要在使用 SaveChanges() 保存实体之前为每个实体设置适当的状态。在上图中，应用程序使用 Context 1 检索实体图，然后应用程序使用 Context 2 执行一些 CUD（创建、更新和删除）操作。在这种情况下，Context 2 不知道对实体图执行了哪些操作。

此场景适用于 Web 应用程序或具有远程数据库的应用程序。