Bounded (Db)Contexts in Entity Framework Architecture

Question

I have just watched Julie Lermans videos about using bounded contexts in EF (http://www.pluralsight.com/training/Courses/TableOfContents/efarchitecture) and I am now trying to work out the best way of implementing it (using POCOs). The two options I see are to either have one edmx model that defines everything and then handcraft the DbContexts to include the appropriate entities, or to have separate edmx models for each context and use the automatically created DbContexts.

Has anyone any ideas of which is best or any pros/cons of either?

IMHO: For a single model it is a lot less classes and a lot more code re-use (though these classes are created automatically so really it will only be the extra functionality that will manually be duplicated), but I will have a lot of classes in one place and for classes that need to be specialised these will each have to have different names. E.g. Customer, CustomerForFunctionalityX, CustomerForFunctionalityB.

With the separate models I can be much more stringent on what goes into a context as removing a property doesn't need to be a completely new entity, and I can name everything as I wish (i.e. all models can use a Customer object even if it differs between models), but now each context has entirely different entities even if they are all just mapping to the same table - which can also make it more difficult to pass them between contexts (this however shouldn't be needed too often otherwise it means the contexts have been defined wrong).

Answer 1

I too am trying out bounded contexts, and have come across a (small?) problem with schemas. I created two contexts initially, one for domain data and one for audit type data (both entity change audit info and process info). Initially, I found that the database only created tables from one context and ignored the other. I assumed that deriving the two contexts from a base context,

    public class BaseContext<TContext> : DbContext where TContext : DbContext

would generate the full database, but did not seem to do so.

One way around this was to create a "master" context which references all entities, but not expose it to the model. This worked ok, but now there is a small problem with db the schemas.

As our support people use SSMS to debug the system, I thought it would be a good idea to change the schema along the same lines as the bounded context, so I specified the schema in the master context (OnModelCreating() override method withing the master context):

    modelBuilder.Entity<Address>()
            .HasKey(b => new {b.AddressId,b.EffectiveStartDate})
            .ToTable("Addresses", "Esr");

where "Esr" is the schema. However, upon trying to write data with the bounded context, an error is occurring which indicates that the bounded context is using "dbo" schema. I'm sure there's a way around this. I do have a nagging feeling that this may not be worth all the effort.

Sure, bounded contexts give a cleaner feel to the application and I like the idea of structuring the code to fit the domain structure, as this puts the overall architecture closer to the specification and helps when thinking about tests.

On the other hand, are my fellow programmers going to have trouble picking the right entities when coding against a single monolithic context?

The separation of contexts is much more useful when applied in the area of support or UAT, and these people have to work with the application in terms of the overall business process.

Answer 2

We are discussing this exact problem now and I too have watched Julies videos as well as researched DDD. I would like my data access to reflect the unit of work but we are running into a problem where a table name cannot be used in more than one EDMX.

Let's say I have tables Customer, CustomerOrder, Order, OrderInventory, Item. On one screen I just want to display the customer information so my EDMX for that only has Customer. Now another use case is I all invoices for a customer, in this use case I have Customer, CustomerOrder, Order, OrderInventory, and Item. We get this exception: The mapping of CLR type to EDM type is ambiguous because multiple CLR types match the EDM type 'Customer'. Previously found CLR type 'A.Customer', newly found CLR type 'B.Customer'.

How are you guys getting around this error message? Are you renaming every table that is duplicated across all the EDMX files?