Decoupling ASP.NET MVC 5 Identity to allow implementing a layered application

Question

I'm new to ASP.NET MVC and I've been developing a MVC 5 application with individual user authentication. I've been doing a layered pattern when doing my applications like separating Model layer, DAL layer, Repos, etc. etc. but now in MVC 5, I want to be able to use the user and role management and authentication which they call Identity, and then still have that layered structure to my application because right now it seems Identity is pretty much coupled with the MVC project itself with the user and role models in there and the context too.

What I did in my application for now is I have all my supposed-to-be-separate layers like my DAL, UnitOfWork, Repos, other models, etc in the MVC project (in separate folders!) just to make it work, for now. And I know it's just not the right way to do it.

So can anyone point me to some good examples or articles about this or explain it directly if it's possible or not and how? Google hasn't been friendly to me about this one. Thanks!

Solution

Here is a quick draft of what I'd try...I would create these layers:

• Contoso.Core (Class Library)
• Contoso.Data (Class Library)
• Contoso.Service (Class Library)
• Contoso.Web.Framework (Class Library)
• Contoso.Web (ASP.NET MVC 5.0)

Contoso.Core:

This layer holds all my entities/classes representing my database TABLES.

So for example, I would have a:

• User.cs class.
• Product.cs class
• ProductDetail.cs class
• Etc..

Some people call these entities/classes: the Domain Objects, others call it the POCO classes.

Either or, these entities/classes are defined in the Core Layer since they may (or may not) be used amongst the other layers.

---

Contoso.Data:

This layer is where I define my ContosoDbContext.cs class. It is inside that file that I have all my DbSet<> defined. So for example, I would have the following inside my ContosoDbContext.cs:

• public DbSet User { get; set; }
• public DbSet Product { get; set; }
• public DbSet ProductDetail { get; set; }

Needless to say, the Contoso.Data layer WILL HAVE A DEPENDECY on the Contoso.Core layer. In addition, it is inside that Contoso.Data layer that I would have my Generic Repository and anything related to "data access".

---

Contoso.Service:

This layer would be where I place all my business rules. For example, I may have a UserService.cs class that could have a Login() method. The Login() method would receive a username/password and call the Repository to lookup the user.

Because the Service layer needs the Repository, I WILL HAVE A DEPENDENCY on the Contoso.Data layer AND because I'll be playing around with the User class (which happens to live inside the Contoso.Core layer), I WILL ALSO HAVE A DEPENDENCY on the Contoso.Core layer.

---

Contoso.Web.Framework:

This layer would have a dependency on the Contoso.Core, Contoso.Data and Contoso.Service. I would use this Contoso.Web.Framework layer to configure my Dependency Injection.

---

Contoso.Web:

The final layer, the MVC 5.0 application, would have a dependency on the Contoso.Web.Framework AND on the Contoso.Service AND on the Contoso.Core layers.

The Controllers, would invoke methods living inside the classes defined in your Contoso.Service layer (for example the Login() method).

The Login() method may or may not, for example, return a User class (null or populated) and because it returns a User class AND BECAUSE we are inside a Controller, our Contoso.Web layer needs a dependency on the Contoso.Service and Contoso.Core.

---

Of course, I haven't detailed everything here or every layer but this is just to give you an example of the type of architecture I’d use.

So far, I haven't answered your question but with little I know about MVC 5.0 and its new Identity mechanism, I believe the Contoso.Core layer would need to have a dependency on Microsoft.AspNet.Identity.EntityFramework in addition to the Microsoft.AspNet.Identity.Core

Likewise, my ContosoDbContext.cs class would need to implement the IdentityDbContext interface which happens to belong to the Microsoft.AspNet.Identity.EntityFramework.dll.

This means my Contoso.Data layer would have a dependency on Microsoft.AspNet.Identity.EntityFramework and most probably the Microsoft.AspNet.Identity.Core as well...

As you say, when you create a new MVC 5.0 project, all of this exist and is defined within the single application. Nothing is or has been decoupled into layers. So in the above architecture the ContosoDbcontext.cs class lives inside the Contoso.Data layer and NOT directly inside the ASP.NET MVC application.

Since I haven't tried the new ASP.NET Identity nor have I tried to decouple things around, I wouldn't know how to honestly answer your question. I guess you'll have to try and move things around.

If and when you do, feel free to tell us how it went and what are the things/problems you encountered.

Meanwhile, I hope this has helped you shed some light (or not).

Vince

Comments

[Bairose]

Thanks @Vlince, this would come in handy. I was hesitant on putting the dependencies of Identity on my Core and Data layers because wasn't so sure how it will play out if I decided to support other app aside from MVC and still reuse the bottom layers when It has dependencies to Asp.Net specific libraries. Anyway thanks, I guess i'll just try it out and I'll be sure to tell about what I encountered. Thanks again!

[Vlince]

I have a similar post here: stackoverflow.com/questions/19715211/…. Basically, I’ve never tried Membership, SimpleMembership or the new ASP.NET Identity. Although I understand why people are using it and why Microsoft creates these APIs but I still believe creating your own login() and stuff gives you more flexibility in terms of what is going on and more importantly, how you want it to be done. But yes, I would be curious to hear about your results.

[Bairose]

I've done what you said. I referenced the dependencies for Identity to the Core and Data layers and I no longer have them on the MVC project itself. But, as expected, the Core and Data layers are now coupled with Identity which just seems weird and I don't know what problems you'll run into when using them on non-MVC apps. But got my app layered so I'm happy with it for now. Thanks!

[Nirman]

@Vince - thanks for the above details... I am trying to implement the similar architecture in my MVC website. However, I am not sure about .Framework layer. Will it be containing the calls to methods we have written in "Service" class library?

[fabriciorissetto]

@Vlince your architecture is almost exactly what I though (except by the .Framework layer) before I start to search another opinions and get here. The only bad thing is the dependency to 'Microsoft.AspNet.Identity' on my Entities project. :'(

[Vlince]

The purpose of this Contoso.Web.Framework is to not have too many things inside the asp.net MVC application. For example, if you plan on having/configuring an IoC container, then your asp.net MVC application will need to add a reference to the Data layer. Since I do not want my MVC layer to see or be aware of the Data layer but at the same time have all my IoC stuff in one place, then that’s why I create this small additional layer called Web.Framework. You can think of this layer as the layer where I configure all the stuff my asp.net MVC application will need.

[matt.]

@Vlince - instead of adding the Identity dependency to Core couldn't you define your User class as you normally would and in your Service layer have your RegistrationService or whatever create a new Identity and a new User?

[Saber]

@Vlince If you put the UserManager in the service layer, you have to pass the dbContext (or IdbContext) from data layer, which I think is wrong. Do you have a solution for it?

[Rod]

@Vlince I have a similar project, but in my Service project i have Manager and Store Identity, What do you think?

[Vlince]

@Rod Since there are many ways to skin a cat, no preferred solution exists. Depending on your level of purism via architecture this may or may not work for you. I posted this about two years ago to give a high level view of what I would have done to decouple the Identity stuff in a layered architecture but didn’t go in full details. If your Manger and Store Identity lives in your Service Layer and that works for you, then great :-)