Asp.net MVC permission design (iii) Background uidesign

Some of my friends asked me to add the details. Some of my friends, PM, said that they could not understand how to use it in many places. Because they are currently in the course center of the school, they have no time to introduce it in detail, here I will design some background information for your reference.

In addition, some modifications have been made to the CenterAuthorizeAttribute section mentioned in the second article, and the original logic judgment BUG will appear.

Permission Category Management SysAppCate

It can be seen that the permission category corresponds to the top menu category. When a new menu category is added, the corresponding items are loaded and displayed.

 

Permission List Management SysAppList

This interface corresponds to all the permissions of the system. Some friends suggested that if the same Action appears, classification management will not be available. In fact, I think it is not, the same Action is generally used in the design of Post and Get request changes. If a page can only be accessed but cannot be operated, is it necessary to present it to the user? Please note that if the setting here shows whether it is true to be: False, the permission will not be displayed in the management menu on the left by group.

 

Permission Group Management RoleGroup

This table is used to create a required system permission group, which makes it easier for us to manage the table. According to my project experience, a project rarely requires hundreds of permission groups. Of course center projects do not involve so many permission classifications.

Here we have an additional "set" option for each permission. Let's see how the "Settings" are completed.

Here I made a Tab to place and load the permissions according to the permission categories. The Start Time and end time control the time that the permission can be operated in the permission group. If the start time and end time are set to Anytime, the start time and end time are set to an indefinite period. I will use declaration and other processes in the middle of the project, so we must control the time to declare as needed.

Here, we should also consider that this data should be submitted only when the permissions are changed. Otherwise, so many permissions are submitted every time for updates. In terms of efficiency, we have made a low-level error. Will be updated to the RoleGroupAppList table.

 

Now, the overall structure of the permissions has been designed. Next, let's take a look at how to apply the permissions to the corresponding users. This is very simple, but I 'd like to explain it a little bit.

Now we only need to assign the corresponding permission group to the user to obtain the permissions assigned to the Group.

 

You can also see that some of my top ones have "help", which is not a fixed page.

<% = Html. actionLink ("Help", "Help", new {c = this. viewContext. routeData. values ["controller"], a = this. viewContext. routeData. values ["action"], controller = "System"}) %>

To create a connection in this form, you can put it in MasterPage. The connection in different pages will actually become the corresponding controller and action, so as to create the corresponding table, you can easily attach help information to this View.

The work at hand has been too busy recently. Due to the tight schedule, I will not discuss it one by one.

 

In fact, MVC gives us greater flexibility and control over views. I have been using MVC for some small projects since MVC1 RC and abandoned my opinion that WEBFORM is relatively bloated. Some friends have also questioned that the MVC programming mode is close to ASP, in fact, this is undoubtedly caused by lack of understanding of the entire MVC Framework and application.