A hierarchical architecture of MVC recommended by Microsoft from Microsoft.AspNet.Identity

Microsoft.AspNet.Identity Introduction

Microsoft.AspNet.Identity is a new membership framework introduced by Microsoft in MVC 5.0, The simplemembership (used in MVC 4) is different from the previous ASP. NET Legacy Membership and webpage.

Microsoft.AspNet.Identity is an implementation of the security standard within the Microsoft Open Owin standard. And in MVC 5, EntityFramework is used by default as the Microsoft.AspNet.Identity data store implementation.

From Microsoft.AspNet.Identity, we can actually see a layered architecture of MVC that Microsoft has adopted, and perhaps we can learn and apply it in our own development.

Microsoft.AspNet.Identity from preview to RC to RTM has always been a change, the following I of course, the structure of RTM to briefly explain this reference layered architecture to learn.

Reference tiered schemas

The first thing to note is that the layered architecture I mentioned above does not refer to the layering of MVC itself, but rather the layering (and coupling) between controller and data.

After you create an MVC project with a separate account management in VS2013, the default is to have a login, register AccountController, through this controller, We can get a glimpse of Microsoft.AspNet.Identity's tolerance distortion.

Let's look at a class diagram first:

From there, we can see the following classes and their relationships:

AccountController

Controller for account management. Has a property named Usermanager, and the type of this property is usermanager<tuser>. and exposes a property named AuthenticationManager, which is of type Iauthenticationmanager.

The controller, as the name implies, only plays the role of controllers, which is to combine M and V, and how to get m to deal with M to get what M, is the business logic thing.

Business logic you can write a dirty in the controller, or you can Microsoft.AspNet.Identity the user-managed business logic into Usermanager as well.

The login and logoff logic is guaranteed to AuthenticationManager, of course AuthenticationManager is actually a Owin interface Iauthenticationmanager, through such a setting, Microsoft.AspNet.Identity is compatible with Owin's security. But I'm not going to talk about Owin's security.

The AccountController provides two construction methods:

1. One of the default:

   Public AccountController () this            (new usermanager<applicationuser> (new userstore< Applicationuser> (new Applicationdbcontext ())))        {        }   

2. One that can be passed to the Usermanager instance:

   Public AccountController (usermanager<applicationuser> Usermanager)        {            Usermanager = Usermanager;        }

Usermanager<tuser> (Microsoft.aspnet.identity,microsoft.aspnet.identity.core.dll)

These are classes of user-managed business logic for a generic type. The reason for generics is that the extension of profile information is supported and is not described in detail here. Usermanager<tuser> simply encapsulates the logic of business processing and does not implement the code for how the data is handled. The relevant code is given to iuserstore<tuser>.

Usermanager<tuser> only provides a constructor that accepts the Iuserstore<tuser> instance:

Public Usermanager (iuserstore<tuser> store);

Iuserstore<tuser> (Microsoft.aspnet.identity,microsoft.aspnet.identity.core.dll)

This interface abstracts the logic of how user data is handled. But the implementation is to be given to specific data access technology-related implementations. From the default constructor of AccountController, we can see that a iuserstore<tuser> implementation userstore<applicationuser> was passed to Usermanager.

Userstore<tuser> (Microsoft.aspnet.identity.entityframework,microsoft.aspnet.identity.entityframework.dll)

This class implements the Iuserstore<tuser> interface and a series of related interfaces (such as:iuserloginstore<tuser>, etc.). This class actually provides Usermanager with access to the real data of the user, where the user data is stored and retrieved through EntityFramework (and the data is actually saved in the various versions of SQL Server or in MySQL, It also depends on the EntityFramework database-driven adaptation layer, which is virtually irrelevant to this layered architecture. And since Userstore<tuser> relies on entityframework to access the data, his constructor also accepts DbContext as a parameter:

Public Userstore (DbContext context);

Although DbContext is a generic class, from the AccountController constructor, we can see that the actual incoming dbcontext is an inherited identitydbcontext<tuser>.

Identitydbcontext<tuser> (Microsoft.aspnet.identity.entityframework,microsoft.aspnet.identity.entityframework.dll)

This is a dbcontext that contains the definition of the Code-first model, which of course defines the users idbset<tuser>, so the operation of the user data is ultimately done by this dbcontext.

A similar architecture explanation

This article (Http://www.codeproject.com/Articles/207820/The-Repository-Pattern-with-EF-code-first-Dependen) actually explains this kind of layered architecture.

Among them, the article mentioned in the IRepository (specific to a domain class Icategoryrepository) is Iuserstore, and categoryrepository is similar to Userstore<tuser> and CatalogService and Usermanager are closer.

Leverage the flexibility of this architecture with dependency injection

From the constructors of these classes above, we can also see that in a variety of important features, that is, several classes have parameter constructors, so the design has to be said to rely on injection to prepare. So, I'll briefly explain how to use unity for simple dependency injection (other dependency injection framework usages are similar).

First, add unity and UNITY.MVC to the two packages through NuGet.

After adding, there will be two files in the App_start folder: UnityConfig.cs and UnityMvcActivator.cs, in the Registertypes function in the UnityConfig.cs file, add the following two lines of code:

            Container. Registertype<iuserstore<applicationuser>, userstore<applicationuser>> ();            Container. Registertype<dbcontext, applicationdbcontext> ();

You can use unity very simply to inject the relevant implementation class into it. So here you can inject your own userstore into it, assuming that your userstore uses a nosql like MongoDB, then you can also inject the MongoDB session into it.

By defining interfaces, implementing them based on interfaces, and exposing constructors with parameters on related classes, you can achieve loose coupling between individual layered implementations and greatly increase the flexibility of your code through dependency injection.

Summarize

In our actual project development, if it is possible to copy this model in order to gain flexibility, it is not a big deal to call DbContext directly in the controller if you just want to implement a prototype quickly or a small project.

update-2013-11-04 For more information about the ASP, you can refer to the official documentation: http://www.asp.net/identity/overview/getting-started

Http://www.cnblogs.com/redmoon/p/3393264.html

Looking at Microsoft's recommended MVC layered architecture from Microsoft.AspNet.Identity