8

I'm building a new MVC application. Normally I always have a project structure that looks like this:

  • DAL layer (entities and repositories
  • Service layer (business oriented service calls that coordinate between the api/Frontend and the DAL)
  • Frontend, this can be web API or MVC application.

My problem is that I always end up with a messy implementation for user management. I used the Membership providers and thus made that part not as nice as it should. Now I saw the new Identity implementation and I really liked it. I did some searches about hot to abstract it to the backend, but with no result.

I found this post about structuring the project but it gave no real answer: Decoupling ASP.NET MVC 5 Identity to allow implementing a layered application

I was hoping someone could provide me with some hints or a technical document how abstract all login and authentication to the backend layer.

Community
  • 1
  • 1
Patrick
  • 2,730
  • 4
  • 33
  • 55

2 Answers2

4

You could create a pretty basic interface in your business layer. It would look something like this:

public interface IAuthenticationService
{
    bool VerifyPassword(User user, string password);

    bool SignIn(User user);

    void SignOut();
}

You can implement this interface using ASP.NET Identity in either the business layer, the UI layer or a seperate infrastructure layer.

This interface could be implemented by different technologies which can be registered at runtime by an IoC container and you could just use the interface in your AccountController for example. Since authentication frameworks tend to change often (every year or so), this allows you to switch more easily.

Henk Mollema
  • 44,194
  • 12
  • 93
  • 104
  • But then how can I use the attributes in my controllers and how to implement the oauth? – Patrick Jan 23 '14 at 13:27
  • 2
    @Patrick if you mean the [`Authorize`](http://msdn.microsoft.com/en-us/library/system.web.mvc.authorizeattribute(v=vs.118).aspx) attribute, you can just use it and ASP.NET Identity will take it into account. It lives in the `System.Web.Mvc` namespace so it has no direct dependency to an authentication implementation. Regarding OAuth, I have no experience with it so I'm not sure if you could abstract it away. – Henk Mollema Jan 23 '14 at 13:45
  • 1
    Just curious has anyone actually pulled this off yet? It sounds simple enough but the route I was headed down can create such a mess due to extensions methods the EF Identity implementation includes in the Account controller. I am literally trying to get to a point where I can pull EF, Identity and EF Identity dependencies from my MVC project entirely. Just wanted to see if anyone had any examples on this/best practices, as mine is a mess that I will probably have to restart on. – Shawn Jun 25 '14 at 12:42
4

Technically, it's already abstracted. The UserManager class, central to ASP.NET Identity, is a wrapper around your database context. Now, if you're talking about abstracting it further, so there's no reference to ASP.NET Identity at all in your code, I'd say that's unnecessary, but still possible. You can simply move all that code into your service layer and then make calls to your service to hit the appropriate methods on UserManager. You'll still need to pass your context around, though, so that you don't end up creating multiple instances of it, which will bite you, for sure.

Chris Pratt
  • 232,153
  • 36
  • 385
  • 444
  • 3
    I dont want to get rid of the asp.net identity in my code. Only get rid of it in the mvc project, and put it in the service layer project. Maybe I indeed should start of with moving all code from the controlller to the service and then see what I should do next. – Patrick Jan 23 '14 at 15:05
  • 1
    @Patrick If you put the UserManager in the service layer, you have to pass the dbContext (or IdbContext) from data layer, which is wrong. Do you have a solution for it? – Saber Sep 26 '15 at 12:37