1

I'm trying to create EF code first with multiple contexts. One context for for StaffContext (HR) and the other is ,ShippingContext.

  1. Is the idea of having multiple contexts has any advantages ? Cause I feel it is complex to construct.

  2. How do we construct the entities ? Define all in base context or in each separate context ?

  3. In these contexts, I need access to Staff entity which when I try to "update-database" will gives me an error since the Staff entity already exist in other context. Is the fact that I have same entity in different context is wrong design ?

This is what I have at the moment :

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>();
    }
}

Thanks a lot in advance.

hollycrab
  • 315
  • 3
  • 13
  • You might want to beware of the contrasting answers this question might cause. You're likely to get answers from people either wearing an 'EF' hat or a 'DDD' hat. One will be data-centric, the other will be domain-centric. Both camps will have different understandings of what the words 'context' and 'entities' mean. – Adrian Thompson Phillips Mar 03 '16 at 10:05
  • Possible duplicate of [EF 6 plus several db contexts](http://stackoverflow.com/questions/24908719/ef-6-plus-several-db-contexts) – guillaume31 Mar 03 '16 at 11:08
  • Hi Adrian Thompson Phillips, Yes, be honest I just starting my self and come across this DDD terms which then I decide to dig more about it. Thanks – hollycrab Mar 03 '16 at 12:26
  • If you really care about *DDD* and *Bounded Context*, then you have to separate the storage. Bounded Context should not have any ability to query outside. – Alexey Zimarev Mar 03 '16 at 18:32
  • Hi Alexey, Thanks for you response. May I ask what you mean by "must use separate storage" ? and for Bounded Context should not query outside, it means that cross query between contexts should not happen right ? Thank you – hollycrab Mar 07 '16 at 10:04

1 Answers1

1

I don't really know why you would want to do that in the first place - having one context you just recreate whenever it is needed is much better and easier in my opinion. However, lets start:

To 1:

  • Multiple contexts can be easier to maintain, because it just splits up code more over multiple objects - if you have problem with one context, you can simply look at the model of it and fix the problem. However, your context shouldn't be too complex anyways.
  • Multiple contexts do have the advantage that each of those does not become too big most of the time, which will bring a performance gain. However, you will throw away EF functionality whenever you try to cross context boundaries, like query creation for joins and relationship fixups.
  • When you access multiple databases with differing schemas or the need for differing models, multiple contexts are the way to go. Also, whenever you do update operations on your database (with SQL, not migrations) you will need multiple contexts to access the different manifestations of updated entities.

To 2:

  • You can't have the same entity in multiple contexts at the same time. This does also mean that you don't have to provide the DbSet's for those entities already contained in another context, unless you can guarantee you will not touch the same objects with differing contexts.
  • When you don't have the DbSets for a entity set, of course you won't need the model configuration for this entity in this context. However, general stuff like conventions and datatype mapping can be done in a base context. Also, this might be the best place for context-related help functions.

To 3, although already mentioned:

  • There can be a place for multiple contexts, but I feel like this should be an exception. When you have multiple contexts, you
  • will run into concurrency errors far more often (since you might change the concurrency items to the same values in different contexts)
  • cannot access EF functionality across those boundaries (like navigation properties, since you can't keep objects of those types in your context inclusively) and
  • can't use the Update-Database/Migrations functionality unless you run the risk to define all entities in both contexts.

I don't feel like it is generally a bad design, however it does bring some problems you will have to overcome, while having all objects in one context does not have many disadvantages, if any.

DevilSuichiro
  • 1,049
  • 8
  • 21
  • Hi DevilSuichiro, Yes, at the moment I also still think that the multiple context will make it easier to maintain, yet single context may not be that harmful as well. I just starting to dig about this DDD, hence just trying stuff myself. Thanks a lot for your response. – hollycrab Mar 03 '16 at 12:29