[Permission System Analysis] clarifies the "module" and "permission" functions (I)

When talking about permissions, most of them are immediately connected to specific application modules. Indeed, such connections are closely, inevitable, and necessary. However, whether or not such "Connections" need to be closely integrated in software design depends on the software scale, application scope, and design complexity. Among the many projects I have experienced, such permissions and modules are generally one-to-one, and the design of these module permissions is similar, which leads to a large number of similarCode. How to better handle the relationship between permissions and modules has become a thing that I cannot forget. I will share some of my ideas with you below.

The main function of "module" is to describe and process the business. Therefore, we should pay more attention to the completion of the business in the module design.

The main function of "permission" is to describe the scope of user operations.

The "permission" is designed based on the "module" and the "module" is controlled based on the information provided by the "permission. UseSQLYou can briefly describe the relationship between them. :

"SelectPermission.Permitted informationFromModuleWherePermission.Condition= True"

From this description, we can see that in most cases, permission control is nothing more than controlling the width and depth of the user in the application, which lays the foundation for permission abstraction.