4

I'm fairly new to the Entity Framework, and am working on a project that is making use of the Entity Framework 6, Identity 2, Web Api 2 and MVC 5.

In the initial workings of the project, I have created a BusinessConnectionsContext to represent the build of my business models. I left the ApplicationDbContext that gets created automatically to its own devices, up until now. I'm mostly focusing on Web Api 2.

In my solution, I have an assembly for my models, which includes the BusinessConnectionsContext and ApplicationDbContext, an assembly for the Web Api, and an assembly for the Web, using MVC5. Both the WebApi and Web assemblies will make use of the Models assembly.

I've come to a point where I need to link ApplicationDbContext users with the BusinessConnectionsContext, but I can't find any information about this. I get the feeling I'm, perhaps, doing it wrong.

Should all the models in the BusinessConnectionsContext be relocated into the ApplicationDbContext?

It seems a fairly hefty move. What would typically happen if you had otherwise unrelated contexts requiring links into identity in the one system?

Reuben
  • 4,136
  • 2
  • 48
  • 57
  • Do you need to reference the Users by anything other than their Id? – Excommunicated Oct 28 '14 at 18:22
  • Not as yet. I've since merged the ApplicationDbContext into the BusinessConnectionsContext, thus making the BusinessConnectionsContext extend the IdentityContext (or whatever it was called). However, because most ApplicationUser operations are serviced by the ApplicationUserManager which is an extension of the UserManager, that uses UserStore, I always have to reference the user in other models via ApplicationUser.Id, and have difficulty loading an ApplicationUser that might be reference by any other model. – Reuben Oct 28 '14 at 23:16
  • I guess I am asking, Are you just needing the currently logged in users information for a specific task, or are you wanting to get any users information? There are a few different solutions, depending on what your actual requirements are. – Excommunicated Oct 30 '14 at 14:10
  • A bit of both. In some cases, if I am getting a model which might reference an ApplicationUser, it would be nice to load that relationship. I now realise that both models have to be in the same context for that to happen. However, the manner in which the ApplicationUser and associated class are done by default (ApplicationUserManager, UserManage, UserStore, etc), still make this a task that is apparently harder than just using Include() on the LINQ statement. – Reuben Oct 30 '14 at 23:20
  • Users are just EF entities. Add the users collection to whatever context you want and you should be fine. – Casey Dec 05 '14 at 19:36

1 Answers1

1

The short answer is all the models should be located in the one context. Either stick with the ApplicationDbContext that is created by default, or make your own. So far, I've not seen anything that deals with an Identity model that might be shared between two contexts, and I don't expect that transactions would extend across multiple contexts either.

As for what happens when you have otherwise unrelated contexts requiring links into identity in the one system? I don't know. I could say that you also have the contexts and models in different name spaces, and only use one context at a time, especially when it comes to updates.

One thing, slightly unrelated to the question, was the issue of the ApplicationUserManager, a wrapper for IUserStore.

I had several projects using the one context, but because they all had different expectations of who was accessing the project (one for admin via web, one for users via web and another for special users via webapi), they all had their own ApplicationUserManager. At some point, I had decided to use Unity to make sure the one context was shared across all repositories and the unity of work. I also had to make sure this context was also used in the IOwinContext that was used by the ApplicationUserManager. Since I'm not an expert in such things, I wont go into detail here (I guess it would the answer for another question), but suffice to say, on the subject of context and identity shared between multiple projects, it's something to keep in mind.

Reuben
  • 4,136
  • 2
  • 48
  • 57