Table-overlapping Database Context in Entity Framework 6 Code First

Question

Is there a possibility to create a table overlapping database context to avoid putting the database context in a library or creating different table prefixes/different databases for the same things?

To elaborate, this is an example of a CRM system.

Database

- Pages
- Categories
- BlogEntries
- Comments
- Products
- Profiles
- Licenses
- Activations
- Invoices
- Customers

DB Contexts

Activation Server Context uses

- Products
- Licenses
- Activations
- Customers

Customer Relationship Context uses

- Products
- Customers
- Invoices

Frontend Website Context uses

- Products
- Customers
- Invoices
- Profiles
- Pages
- Categories
- BlogEntries
- Comments

Solutions

The only ways I could think of doing this...

Creating one library with one db context that addresses all tables (incl. migrations etc.) -> Separation of concern?
Splitting up related tables into different contexts with prefixes/database split -> Related table entries are not "tied together" (and I have to use guids to avoid duplicates, also using multiple contexts in one project)

What's the problem with defining a different context for each application domain? Why do you need prefixes/database split (I don't know what the latter means)? What do you mena by "Related entries are not tied together"? — JotaBe
– JotaBe, Commented Nov 24, 2014 at 11:19

Brett Green · Accepted Answer · 2015-04-20 19:57:01Z

1

This is the primary reason I've avoided Domain Driven Design is because of questions like this.

I'd just have one big context... it's a repository wrapper and your repository is what it is. If you store everything in one big DB, then your context/repository should be one big repository, IMO.

It's not a separation of concern issue, in my opinion. in the sense that the context wraps repository concerns only, not business logic around those entities... it does one thing: Serialize and Deserialize data/entities from permanent storage.

We experimented about 4 years ago with domain driven design and we found that we were repeatedly having these fairly meaningless debates about 'does product belong in Domain 1 or Domain 2'. This is a real drag on productivity and it's really because DDD doesn't really fit most real world scenarios because overlap is the norm not the exception.

edited Apr 20, 2015 at 19:57

answered Apr 16, 2015 at 20:06

Brett Green

3,7761 gold badge24 silver badges32 bronze badges

Sign up to request clarification or add additional context in comments.

Collectives™ on Stack Overflow

Table-overlapping Database Context in Entity Framework 6 Code First

Database

DB Contexts

Solutions

1 Answer 1

Comments

Your Answer

Hot Network Questions

Collectives™ on Stack Overflow

Database

DB Contexts

Solutions

1 Answer 1

Comments

Your Answer

Sign up or log in

Post as a guest

Related