Код сначала EF с несколькими контекстами

Question

Я пытаюсь создать код EF сначала с несколькими контекстами. Один контекст для StaffContext (HR), а другой - ShippingContext.

1. Есть ли у идеи множественные контексты какие-либо преимущества? Потому что я чувствую, что это сложно построить.

2. Как мы строим объекты? Определить все в базовом контексте или в каждом отдельном контексте?

3. В этих контекстах мне нужен доступ к объекту Staff, который, когда я пытаюсь «обновить-базу данных», даст мне ошибку, поскольку объект Person уже существует в другом контексте. Является ли тот факт, что у меня одна и та же сущность в другом контексте, неправильный дизайн?

Это то, что у меня есть на данный момент:

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 для тех объектов, которые уже содержатся в другом контексте, если вы не можете гарантировать, что не будете касаться одних и тех же объектов с разными контекстами.
• Если у вас нет DbSets для набора сущностей, вам не понадобится конфигурация модели для этого объекта в этом контексте. Однако общие вещи, такие как соглашения и сопоставление типов данных, могут выполняться в базовом контексте. Кроме того, это может быть лучшим местом для контекстных функций справки.

3, хотя уже было сказано:

• Там может быть место для нескольких контекстов, но я чувствую, что это должно быть исключением.Когда у вас есть несколько контекстов, вы,
• , чаще сталкиваются с ошибками параллелизма (поскольку вы можете менять элементы параллелизма на одни и те же значения в разных контекстах)
• не может получить доступ к функциям EF через эти границы (например, свойства навигации, поскольку вы не можете хранить объекты этих типов в своем контексте включительно), и
• не может использовать функциональность Update-Database/Migrations, если вы не рискуете определить все сущности в обоих контекстах.

Я не чувствую, что это обычно плохой дизайн, однако это не принесет некоторые проблемы, которые предстоит преодолеть, имея при этом все объекты в одном контексте, не имеет много недостатков, если таковые имеются.