4

I need to start a new mvc project and as always I have issues about asp identity, never know where to put it!

I plan to organize solution like this:

  • ProjectWebUI - mvc app with asp identity framework (made from internet template with authentication)
  • ProjectDataAccessLayer - with repository classes that use dapper as database access technology
  • ProjectWebAPI - web service

But I have a little confusion and before start coding I need advice from someone more experienced (as until now all my projects were just one project with data access in it):

  1. Is it good idea to have asp identity inside WebUI project that use standard Entity Framework for data access and use dapper for other data access in separate assembly?
  2. If asp identity is inside WebUI project will I have some issues to receive authenticated access to WebAPI project?
halfer
  • 19,824
  • 17
  • 99
  • 186
1110
  • 7,829
  • 55
  • 176
  • 334

1 Answers1

2

That's how I organized one of my recent projects:

  • Common — this is a core project in the solution. It contains all the domain entities along with the ApplicationUser class that inherits from IdentityUser class from ASP.NET Identity Framework. Normally this class is found in a new ASP.NET MVC project template; I decided to put it into the core library because it represents a common entity that may be required for higher layers and levels of abstraction. Because of this, Common references Microsoft.AspNet.Identity.Core and Microsoft.AspNet.Identity.EntityFramework assemblies.

  • DataAccess — this project references Common library and contains Entity Franework DatabaseContext as well as some repositories. I use Code First approach and my DatabaseContext is inherited from IdentityDbContext<ApplicationUser>. So it gives me a nice database structure with tables for Users and Roles and other ASP.NET Identity stuff as well as tables that represent my custom business entities from the Common project, so I can easily connect my custom entities with Identity objects.

  • WebApi — this is a REST service that uses DataAccess and Common libraries. All the authorization and authentication job is done here using token authentication.

  • Web — this is just a web client for my REST service.

So, to answer your question: you can keep your ASP.NET Identity classes and Entity Framework database context inside a single project if it is really small and easy to manage; otherwise, it would be better to step away from the default project template and introduce layers for each major application module.

Sergey Kolodiy
  • 5,829
  • 1
  • 36
  • 58
  • So you didn't changed anything inside AccountController? I ask this because that controller talks directly to database and is there a real reason to move each data access from there to separate assembly (DAL)? – 1110 Dec 07 '14 at 18:40
  • @1110 Yes, I changed `AccountController` to use `DatabaseContext` from the `DataAccess` project. If your project is not really tiny or if you want to implement other clients for your WebApi, you should definitely move data access logic from there into a separate assembly. – Sergey Kolodiy Dec 07 '14 at 18:49
  • So that means that I should move login, register and all other user related fuctions out of accountcontroller to dal? Or just DbContext? – 1110 Dec 07 '14 at 19:14
  • Move just `DbContext` to the data access layer. To implement register/login functionality in your `AccountController`, use `ApplicationUserManager` which (indirectly) depends on the `DbContext`. – Sergey Kolodiy Dec 07 '14 at 19:22