具有多个上下文的代码优先 EF

Question

我正在尝试首先使用多个上下文创建 EF 代码。 一种用于 StaffContext (HR) 的上下文，另一种是 ,ShippingContext。

1. 拥有多个上下文的想法有什么优势吗？因为我觉得构建起来很复杂。

2. 我们如何构造实体？在基本上下文中或在每个单独的上下文中定义所有内容？

3. 在这些上下文中，我需要访问 Staff 实体，当我尝试“更新数据库”时，它会给我一个错误，因为 Staff 实体已经存在于其他上下文中。我在不同的上下文中拥有相同的实体是错误的设计吗？

这是我目前拥有的：

public class StaffContext : BaseContext<StaffContext>
{
    public DbSet<StaffPosition> StaffPositions { get; set; }

    public DbSet<Staff> Staffs { get; set; }

    protected override void OnModelCreating(DbModelBuilder modelBuilder)
    {
        modelBuilder.Conventions.Remove<PluralizingTableNameConvention>();
    }
}

public class ShippingContext : BaseContext<ShippingContext>
{
    public DbSet<Armada> Armadas { get; set; }

    public DbSet<Product> Products { get; set; }

    public DbSet<Shipment> Shipments { get; set; }

    public DbSet<ShipmentDetail> ShipmentDetails { get; set; }

    public DbSet<ShipmentHandler> ShipmentHandlers { get; set; }

    public DbSet<ShipmentOrder> ShipmentOrders { get; set; }

    public DbSet<ShipmentOrderDetail> ShipmentOrderDetails { get; set; }

    public DbSet<Staff> Staffs { get; set; }

    public DbSet<Pangkalan> Pangkalans { get; set; }

    protected override void OnModelCreating(DbModelBuilder modelBuilder)
    {
        modelBuilder.Conventions.Remove<PluralizingTableNameConvention>();
    }
}

非常感谢。

Answer 1

我真的不知道您为什么首先要这样做 - 在我看来，拥有一个您只需在需要时重新创建的上下文会更好、更容易。但是，让我们开始吧：

到1：

• 多个上下文可以更容易维护，因为它只是将代码更多地拆分到多个对象上 - 如果您对一个上下文有问题，您可以简单地查看它的模型并解决问题.但是，无论如何，您的上下文不应该太复杂。
• 多个上下文确实具有这样的优势，即每个上下文在大多数情况下都不会变得太大，这将带来性能提升。但是，每当您尝试跨越上下文边界（例如为连接和关系修复创建查询）时，您都会放弃 EF 功能。
• 当您访问具有不同架构或需要不同模型的多个数据库时，可以使用多个上下文。此外，每当您对数据库执行更新操作（使用 SQL，而不是迁移）时，您将需要多个上下文来访问更新实体的不同表现形式。

到2：

• 您不能同时在多个上下文中拥有相同的实体。这也意味着您不必为已包含在另一个上下文中的那些实体提供 DbSet，除非您可以保证不会接触具有不同上下文的相同对象。
• 当您没有实体集的 DbSet 时，当然在此上下文中您不需要此实体的模型配置。但是，可以在基本上下文中完成约定和数据类型映射等一般内容。此外，这可能是上下文相关帮助功能的最佳位置。

至 3，虽然已经提到：

• 可以有多个上下文的位置，但我觉得这应该是一个例外。当你有多个上下文时，你
• 会更频繁地遇到并发错误（因为您可能会在不同的上下文中将并发项更改为相同的值）
• 无法跨这些边界访问 EF 功能（例如导航属性，因为您不能将这些类型的对象包含在上下文中）和
• 无法使用更新数据库/迁移功能，除非您冒着在两种上下文中定义所有实体的风险。

我不觉得它通常是一个糟糕的设计，但它确实带来了一些你必须克服的问题，而将所有对象放在一个上下文中并没有很多缺点，如果有的话.