The body of the

Preface: “We have an order list and hope to see different types of order data according to different users who log in at present”, “We hope that different users can see the scan report data in different periods”, “our system needs different users to view different production report columns”. As such, recently we often received the project above the customer raised this kind of problem, namely the so-called “data authority”, after a meeting discussion decided: in the current development framework to build a set of general data authority functions.

One, the big talk permission module

With the above introduction, it naturally leads to the topic we need to discuss today — data permissions. As a developer, we certainly know that the general system is inseparable from the permission module, it is to support the whole system to run the basic module. According to different project types and requirements, the design of permission modules is quite different. But no matter how to change, permission module from the big aspect, can be divided into two kinds of big types: functional permission and data permission.

  • Function rights: Controls the rights of different resource subjects (users, roles, and organizations) to operate different resources. For example, common different roles can access different pages (menu permissions), as well as different functions of the operation of the same page (button permissions) and so on, are the scope of data function permissions, this design is relatively simple, but also more common for most systems. Of course, online information, design ideas can also be found a lot.
  • Data permissions: It mainly controls the permissions of different resource subjects (users, roles, organizations, etc.) to view different data information. Generally speaking, data permissions are divided into data row permissions and data column permissions. It is hoped that different types of order data can be seen according to the different users currently logged in “, which is a typical data row permission, and “our system needs different users to view different production report columns”, which is the scope of data column permission. Because data permissions are closely related to the business logic of the system, different system designs vary greatly. On the other hand, due to the strong correlation between data permissions and business logic, if the business logic of the system is very complex, the design of data permissions will be relatively complex, so there is no relatively universal and simple design scheme for the design of data permissions.

If you start to design data permissions, when you go to various platforms, Baidu, Google to search for design ideas, you will find it difficult to find useful information, many design ideas are very limited. The reason is simple: the design of data permissions is closely related to other systems, and it is not easy to get access to your project and use it directly.

Of course, there are others who say that “data permissions cannot be designed as permission modules”, such as one blogger who read this comment


From a certain extent, so that to understand too much, if you think your system configuration flexibility and doesn’t need so high, write data access rules inside the code what are dead, the blogger did another department in the company, in addition to the amount of code a bit bigger, in fact also nothing important great problem! In fact, the blogger said so much is just to express a point of view: there is no absolutely universal data permission design ideas, the key is to see if you use it! Of course, the design of this article is the same, not mandatory, not to mention general. Design ideas for your reference!

Two, a design idea

This is the end of all the chatter about the design of permissions. One relatively well-written article that the blogger has found so far is data permissions for a generic permission management design. This blogger is implemented in SQL. If this is applied to EF, there are some problems, considering the complex navigation properties of EF. Here is the design idea that the blogger came up with.

The project is based on EntityFramework+Repository. The whole project is a typical “pseudo-DDD” from top to bottom. What is “pseudo-DDD”? Without going into too much detail here, it should be clear to anyone who has used DDD. Here is the flow chart of design ideas:

Step 1: Configure the data rules


Step 2: The page uses data rules


The above is a general idea. In general, there are two main steps to implement ef-based data permission design

1. Configure data rules

There are three major aspects of configuring data rules: function modules, data resources, and roles

  • Functional modules: Why the constraint of functional modules? The reason is that the blogger thinks that when we query data on a certain page, there will be a query scope. For example, the order query page must only query the entity functions associated with the order, and it is impossible to query the businesses that are not associated with it. The greater significance of this constraint is that we dynamically construct lambdas to query entities without generating errors such as “unable to find associated entities”.
  • Data resource: Specify which data resource to grant data permission to, for example, order status is not equal to cancel state, order time is less than the current month, and so on.
  • Role: The principal of a data resource, which can also be a user, department, organization, and so on.

One result of these three configurations is what the data rules are for a certain functional module of a certain role for which data resource. For example, if there is a data rule for the sales director, configure the sales director to place orders in the order module. The order type of this entity is all the data of the sales order. This is the data rule for the sales director in the order module. You might end up with a database that stores something like this:


In particular, EF has the navigation attribute. If the Rules here meet the navigation attribute, our field value should be “product.categary.Type”. Because when we convert to a lambda expression the navigation property will be x=> x.product.Categary.Type==1. We will explain this later when we use this rule.

2. Use data rules

We need to pass two parameters, one is the name of the module, such as OrderQuery, Product, etc. The second is the role ID of the current user, which can be obtained by the id of the current logged-in user.

To use the data rules, the blogger shared two previous articles on dynamic lambdas, which come in handy. It’s just that it used to be just some basic type lambda, but now it involves navigation properties, I don’t know if that’s possible. The blogger did some digging and eventually found a solution.

Public Expression GetProperty(Expression source, ParameterExpression para, string Name) { string[] propertys = Name.Split('.'); if (source == null) { source = Expression.Property(para, typeof(Entity).GetProperty(propertys.First())); } else { source = Expression.Property(source, propertys.First()); } foreach (var item in propertys.Skip(1)) { source = GetProperty(source, para, item); } return source; }Copy the code

Then the test is as follows

var oLamadaExtention = new LambdaExpression<Order>(); var left = oLamadaExtention.GetProperty(null, Expression.Parameter(typeof(Order), "x"), "Product.Categary.Type"); var value = Expression.Constant("1", left.Type); Var right = expression. Constant(value, left.type); Expression expRes = Expression.Equal(left, right);Copy the code

The lambda result of the test is x=> x.product.Categary.Type==”1″.

3. Add one more thing

Another bit of trouble when configuring data rules is how do you know which functional modules use which entities? You can’t simply ask users to write “Product.Categary.Type” and other complex functions. Another solution is to reflect EF entities.

If EF entities are navigation attributes, they must be reflected again. In this way, Categary.Type structures such as Product. Here’s the idea:


Third, summary

The above is just a design idea, theoretically it can be realized, if there is any deficiency, welcome to correct, thank you. If there is no problem with the idea, the subsequent blogger will spare time to show the implementation process of this design for your reference, welcome to follow. There are two difficulties:

1. Step by step reflection of EF’s navigation properties, and how this process unfolds. Whether by feature marking or developer configuration;

2. Dynamic Expression has compatibility issues with configuration data when constructing Lambda, such as data type compatibility is a bit difficult to control.

Too lazy to settle down


Original address:
Data authority design – based on EntityFramework data authority design scheme: a design idea – lazy and easy – blog park


Copyright: This article is by the happy science and technology cooperation blogger original, reproduced please indicate the author and source, thank you!


Snap up wechat mini program for one yuan >>>
The link address