Do I add the same table in multiple entity framework bounded context

Question

I have a fairly big database, about 80 tables or so. So I've decided to separate the tables into bounded context instead of having all 80 tables in 1 big edmx file.

So I have bounded contexts like Sales, Customers, etc.

I have my main customer table within my Customers edmx file. However, I also need to access certain fields, not all, but 1 or 2 fields (e.g., I just need customer name, instead of the whole customer object/table) from the customer table from the Sales edmx context.

Do I have to add the whole customer table into the Sales edmx file? What's the best practice for this scenario?

Answer 1

I like Julie Lerman's view on this topic http://msdn.microsoft.com/en-us/magazine/jj883952.aspx

I use bounded contexts for access performance since the load time of Contexts is faster when using smaller dbcontexts even when using generated views. Simplyfying the access model is nice extra. performance consider tips on MS ef site: http://msdn.microsoft.com/en-us/data/hh949853

BCs also allow other benefits such as restricting access to match business problem. The bigger issues arise if you try and work with db contexts that vary not just in which DBSet appear, but your try and alter the Model views. I think that is best done outside of EF and mapped.

I use one large SUPERSET Context to manage the DB creation/migration. But not Day to day access.

Smaller DBcontexts are used for everyday all day access to data.

So yes by all means use bounded contexts. This can be against the SAME data store. And to answer the question as worded "Yes the same table (DbSet) can appear in many contexts.

Answer 2

There are a couple of underlying issues with this approach (IMO):

EF, like any ORM, falls into the persistence concern. As such it should not be interfering with how you structure your domain model. The fact that you have all your entities persisted in what sounds like one persistence store may be an indication that your bounded contexts are overlapping or are non-existent.

Trying to move to a better structure is not a bad thing :) --- however, as Mark Oreta stated, I probably wouldn't bother with the EF structure.

The primary issue you are running into is caused by trying to read from your domain model. This seems to crop up all too often in systems and it makes things rather difficult. Lazy-loading is the direct result of exactly this. When you read you should, ideally, be using a query layer with access to a query store (may be the same database) that is optimized for reading. In your example you need a denormalized customer name in your sales domain. That is fine. Trying to get that by reading your domain model and then trying to pull in data from a domain model in another bounded context is what is causing you the pain.

If you go down the route of splitting your data then you will need to keep it split.

Although the data from various BCs may all be in the same store you should think of your data as though each BC has its own database. Sometimes I have a single project with various concerns (layers to some) in different folders/namespace (.NET here). It should be possible to split out those concerns into separate assemblies on a whim. So they should not be too tightly coupled. The same goes for this data structure you are attempting to split. You should in essence be able to split out the relevant BC data to a separate database. The mechanisms for getting data across the BCs is another matter and I guess if that cannot be addressed you may find it tough going.

Although I don't think that identifying BCs from the data side may be best idea it is certainly a step in the right direction :)