ASP.NET MVC5 Entity Design Linking Tables in Different Databases - asp.net

Question

I am working with a Database First design using ASP.NET and MVC5. I have followed several tutorials in an effort to learn this and in every one of these I end up with my security-related tables (users, roles, etc.) in a completely separate database from my other application data. This is not a problem however I can't seem to figure out how to create relationships between my application tables (which often need to contain the UserId for example) and the AspNetUsers table. I've searched for examples online and can't find any.
I have attached a very simple example; a table in which I need to link specific users (from the table AspNetUsers) to specific companies (from the table Company). As you can see, I know how to create the relationship between this new table and the Company table, but how do I create the relationship between this new table and the AspNetUsers table?
Can someone help me understand how this is done? Thanks!!

Answer 1

You can't. Foreign keys can't span databases, so there's no way to create a hard relationship between the two entities in two separate databases. All you can do is store the id, and then manually query the other database for that id when you need that entity.
For example, given:
public class Company
{
...
public virtual ICollection<UserCompany> UserCompanies { get; set; }
}
public class UserCompany
{
[Key]
public int Id { get; set; }
public int UserId { get; set; }
// Can't create a foreign key here, because the user table is
// in another database
[ForeignKey("Company")]
public int CompanyId { get; set; }
public virtual Company Company { get; set; }
}
Then, you could do:
var userIds = someCompany.UserCompanies.Select(m => m.UserId);
var users = userContext.Users.Where(m => userIds.Contains(m.Id));

Answer 2

Not possible.
For the best solution you probably want to go with something like this: Multiple contexts with Entity Framework 6, reference entities across dbcontexts
That abstracts away your concerns so you can use a single context. However, if you're dead set on using two contexts and need to insert data you're going to have to maintain these relationships yourself in your code. For example, you can override ValidateEntity for the dependent entity such that it checks the other context and verifies that the required entity exists. This adds a lot of complication though, because you need to ensure your save changes is called in the correct order (i.e. the required entity context is saved before the dependent entity context is saved), and it could also add some snafus with TransactionScopes. I don't know how well a transaction across two databases will be rolled back.
For reads though, you just have to read the objects from both contexts and manually build up your object graph yourself.
Seriously though, I highly recommend abstracting this away at the database.