Handling foreign keys in multiple contexts/domains using Entity Framework Code First and Migrations

Question

I'm building a new system that utilizes data from an existing legacy system. A requirement is for our application to use the same physical database but a different schema for isolation. Our application will need read access only from the dbo schema, but our new structure will have foreign keys from the dbo schema so we'll need to enforce that.

I'm planning on creating two different projects with two different contexts. This will facilitate using Reverse Engineer Code First from EF Power Tools on the dbo schema, and using EF Migrations on our new schema. However, I'm unsure how this approach will handle Foreign Keys across contexts/domains. How would I map these so Migrations interprets it correctly?

Did you ever find a solution for this problem? – JasonlPrice Jan 15 '15 at 15:32 — JasonlPrice, Jan 15 '15 at 15:32
No, the joining across contexts was always manual. – Mike Cole Jan 15 '15 at 15:37 — Mike Cole, Jan 15 '15 at 15:37

score 1 · Answer 1 · edited Apr 23 '18 at 09:54

If you use different schemas and\or different contexts, that means this data can be stored anywhere, even at different storages (files, azure, services). You should not use explicit foregin keys across across contexts/domains. You have to make separate queries to each contexts.
If you really need to do that, you can use databse VIEWS with any joins you need (even from other server). Then just map our EF entity to view:

[Table("MyView")]

public class MyEntity {...}

Obviously, it will read-only entity.

Handling foreign keys in multiple contexts/domains using Entity Framework Code First and Migrations

1 Answers1