Entity Framework relationships between different DbContext and different schemas

Question

So, I have two main objects, Member and Guild. One Member can own a Guild and one Guild can have multiple Members.

I have the Members class in a separate DbContext

Answer 1

I have found that when I am having problem with Entity and building relationships it's often because I am going against the flow of the framework or trying to build relationships or abstractions that are not technically well-formed. What I would suggest here is to take a quick step back and analyze a few things before looking deeper into this specific issue.

First off, I am curious why you are using different schema here for what is likely a single application accessing an object graph. Multiple schemas can be useful in some context but I think Brent Ozar makes a very salient point in this article. Given that information, I am inclined to first suggest that you merge the multiple schema into one and push over to using a single DB context for the database.

The next thing to tackle is the object graph. At least for me the biggest struggles I have had with data modeling are when I don't first figure out what questions the application has of the database. What I mean by this is figure out what data does the application want in its various contexts first and then look at how to optimize those data structures for performance in a relational context. Let's see how that might be done ...

Based on your model above I can see that we have a few key terms/objects in the domain:

• Collection of Guilds
• Collection of Members
• Collection of Guild Leaders.

Additionally we have some business rules that need to be implemented:

• A Guild can have 1 leader (and possibly more than 1?)
• A Guild Leader must be a Member
• A Guild has a list of 0 or more Members
• A Member can belong to a Guild (and possibly more than 1?)

So given this information let's investigate what questions your application might have of this data model. I the application can:

• look up a member and see their properties
• look up a member and see their properties and that they are a guild leader
• look up a guild and see a list of all its members
• look up a guild and see a list of guild leaders
• look up a list of all guild leaders

Ok, now we can get down to brass tacks, as they say...

The use of the join table between Guilds and Members is optimal in this instance. It will provide you the ability to have members in multiple guilds or no guilds and provide a low locking update strategy - so good call!

Moving onto Guild Leaders there are a few choices that might make sense. Even though there may never be a case for say guild sergeants, I think it makes sense to consider a new entity called a Guild Leader. What this approach allows for is several fold. You can cache in app the list of guild leader ids, so rather than make a db trip to authorize a guild action taken by a leader you can hit local application cache that only has the leader id list and not the whole leader object; conversely, you can get the list of leaders for a guild and regardless of the query direction you can hit clustered indexes on the core entities or the easy-to-maintain intermediate index on the join entity.

Like I noted at the start of this way to long "answer", when I run into issues like yours, it's typically because I am going against the grain of Entity. I encourage you to re-think your data model and how with a lower friction approach - loose the multiple schema and add an intermediate guild_leader object. Cheers!