How to create asp .net mvc 5 applications with three-tier architecture using identy 2.0?

I have an ASP.NET MVC5 application consisting of three layers: PLL, BLL, DAL. In DAL there are repositories for working with the database, in BLL there are helpers for each entity. Models, views and controllers are directly located in the PLL, BLL methods are naturally used in controllers.

In addition, the PLL contains Identy 2.0 classes. That is, in my application there are two Db contexts, which will undoubtedly lead to collisions.

I want to learn how to distribute Identity 2.0 classes in my application so that they use the only DB context located in the DAL. That is, there is a goal to remake FULLY my application for a three-layer architecture.

  • one
    What do you mean by "right"? MVC is simply a pattern of a Presentation organization, one of three levels. Stick to the pattern, do not write the business logic code in the controllers, and everything will be more or less correct. - PashaPash ♦
  • one
    Probably what is meant is that the identity is bullet into the base, which with 3 links is not directly accessible from the site. - cpp_user
  • 2
    I vote for closing this issue as not relevant, because the question is too general and may have a specific solution. - Cerbo
  • one
    What is there in common? You need to implement your custom user provider for identities in order to transfer data through the three-link system to your storage. - cpp_user
  • one
    @Nicolas Chabanovsky is a comment, not an answer. - Mstislav Pavlov

2 answers 2

If you are not satisfied with the standard methods that Identity 2.0 works with the base, you can completely replace it with your own:

Announce your type to the user:

public class ApplicationUser : IUser { ... }

Declare your own user repository type and implement it using an existing BLL / DAL:

 public class CustomUserStore : IUserStore<ApplicationUser> { ... }

Declare a heir from UserManager:

 public class CustomUserManager : UserManager<ApplicationUser> { public CustomUserManager(CustomUserStore store) : base(store) { this.PasswordHasher = new CustomPasswordHasher(); } public static CustomUserManager Create(IdentityFactoryOptions<CustomUserManager> options, IOwinContext context) { var manager = new CustomUserManager(new CustomUserStore<ApplicationUser>()); return manager; } }

and register the CustomUserManager in App_Start:

 app.CreatePerOwinContext<CustomUserManager>(CustomUserManager.Create);

CustomUserStore and CustomUserManager relocate or in BLL, or partially leave in the PLL (depending on how you implement them). I would leave them in the PLL by writing BLL calls in their methods.

Or, perhaps, the standard implementation of UserStore will be enough for UserStore , then it will be enough to create an empty class that CustomUserManager and register both it and the factory for the shortcut:

 public static ApplicationDbContext Create() { return new ApplicationDbContext(); } public static CustomUserManager Create(IdentityFactoryOptions<CustomUserManager> options, IOwinContext context) { var manager = new CustomUserManager((new UserStore<ApplicationUser>(context.Get<ApplicationDbContext>()));); return manager; } public void ConfigureAuth(IAppBuilder app) { app.CreatePerOwinContext<ApplicationDbContext>(ApplicationDbContext.Create); app.CreatePerOwinContext<CustomUserManager>(CustomUserManager.Create); }

I did not check the code live, but it should work

    Here, the process of implementing Identity into a three-tier architecture is well described.