Read catalog

text

Preface: "We have a list of orders, hoping to see the different types of orders data according to different users currently logged in", "We want different users can see the scan report data in different time periods," "We need a different system users View different production report columns. " And so on, recently received this question often raised by customers above project, the so-called "digital rights", after a meeting to discuss the decision: In the current development framework built on top of a common set of data permissions feature.

This article Original Address: http://www.cnblogs.com/landeanfen/p/7760803.html

back to the top

First, lying permissions module

With the above introduction, naturally leads to the topic of discussion today and needs - Data permission. As developers, we know for sure, the general system can not do without permission module, which is to support the basic module of the whole system. And depending on the type and requirements of the project, design rights module is different. But no matter how they change, permissions module from the big side, it can be divided into two major types: functional privileges and data rights .

Function rights : The main body control different resources (users, roles, organizations, etc.) have authority to operate different resources. Such as common different roles can access different pages (menu rights), as well as with different functions (buttons authority), etc. operations the same page, all data function right category, this design is relatively simple and more for most the universal system. Of course, online information, design ideas also can find a lot.
Data permissions : Different main body control resources (users, roles, organizations, etc.) have permission to view different data, in general, data authority is divided into rows of data rights and data columns authority , by the literal meaning is not difficult to understand the difference between the two, such as the above "we have a list of orders, hoping to see the different types of orders data according to different users currently logged in" this is a typical data line authority, and "we need a different system users to view different production report column "this is the category of data column permissions. As the business logic and data rights system is very close, so different design will be a very big difference. On the other hand, since the data authority and associated business logic is very strong, if the business logic of the system is very complex, data rights will be relatively complex design together, so the design data about the authority has not been a relatively common and easy to use It designs.

If you go hands-on design data permissions, when you go to the major platform, Baidu, Google look for design ideas, you'll find it difficult to find useful information, many of the limitations of design ideas is very large. Actually, the reason is simple: design and data rights of others systems close relationship, usually not easy to get used directly on top of your project.

Of course, there is another part of the people say, "data rights and can not serve as permission to design modules," such as bloggers see such a comment

To some extent, this understanding is not excessive, if you feel that your system flexibility and configurability do not need so high, the rules of data written permission of dead code inside no harm, another department where the company's blogger It is so dry, in addition to coding large that it is not too much of a problem! So much in fact, bloggers simply want to express a point of view: there is no absolute rights common data design ideas, the key to fit together with you! Of course, this article is the same design ideas, not mandatory, not to mention common. Design ideas for your reference!

back to the top

Second, one design ideas

On design topics for permission to come to an end, all superficial, say more say rotten. So far, bloggers find a relatively well-written article data rights management design of universal rights . The bloggers are using sql to achieve, if this is applied to the inside, then EF, EF taking into account the complexity of navigation attributes, there will be some problems. Then talk about design ideas bloggers here think of.

Let us talk about the case of projects where the bloggers, some dealing with traditional data and model EntityFramework + Repository is to be achieved, the entire project from top to bottom, is a typical "pseudo-DDD", what is "pseudo-DDD"? Do not do much to explain here, used DDD colleagues should be very clear. The following is a flowchart illustrating design ideas:

Step 1: Configure Data Rules

Step Two: page uses data rules

The above is a rough idea of drawing, in general, to achieve design data authority EF based mainly divided into two steps

back to the top

1, the configuration rule data

Configure data rules here are three major areas: functional modules , data resources , role

Function Module: Why here to add constraint function module? Because we feel that the bloggers in one page query the data, when there will be a range of queries, such as page order inquiry certainly can query and order an entity linked to the function, but can not query and it does not have any associated business. Plus the greater significance is bound to query a dynamic entity when we construct Lambda does not produce the error "No entity associated with a" like .
Data Resources: specific kind of data resources to do data rights, such as the status of the order is not equal to cancel the state, under the orders of a single time is less than the current month, and so on.
Role: main data resources, but also can be users, departments, organizations, and so on.

这三者配置之后得到的一个结果就是某一类角色的某一个功能模块对哪个数据资源的数据规则是什么样的。比如有一条销售总监的数据规则，配置销售总监在订单模块里面订单这个实体的订单类型是销售订单的所有数据，这就是针对销售总监在订单模块的数据规则。可能最终数据库存储得到的数据类似这样：

RoleId	FunctionCode	Rules
2	OrderQuery	{"rules":[{"field":"Order_Status","operate":"in","value":"[0,1,2]"},{"field":"Order_Type","op":"equal","value":"1"}],"logicoperate":"and"}
3	OrderQuery	{"rules":[{"field":"Order_Status","operate":"in","value":"[0]"},{"field":"Product.Categary.Type","equal":"equal","value":"1"}],"logicoperate":"and"}
5	Product	{"groups":[ {"rules":[{"field":"Order_Status","operate":"in","value":"[0,5,10]"},{"field":"Order_Type","op":"equal","value":"1 "}],"logicoperate":"and"}, {"rules":[{"field":"LineName","operate":"equal","value":"fenzhuangxian"}]} ],"logicoperate":"or"}

需要特别说明的是：由于EF有导航属性，这里的Rules在保存的时候如果遇到导航属性，我们的字段值需要这样保存——Product.Categary.Type。因为在我们转换成为lambda表达式的时候导航属性会是这样写：x=>x.Product.Categary.Type==1。这个我们在后面使用这个规则的时候加以说明。

回到顶部

2、使用数据规则

有了上面的数据规则，接下来就是我们在取数据的时候如何使用了，这里有一点需要说明的是：我们这里需要传两个参数，一个是模块的名称，比如上面的OrderQuery、Product等；第二个是当前用户的角色id，这个可以通过当前登陆用户的id获取到角色。

要使用数据规则，之前博主分享过两篇关于动态Lambda的文章，现在派上用场了。只不过原来只是一些基础类型转lambda，现在涉及到了导航属性，不知道是否可行。博主查阅了一些资料，最终找到了解决方案。

　　　　 //遍历得到属性（包括遍历导航属性）
        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;
        }

然后测试如下

　　　　　　　　　　　　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);

测试得到的查询lambda结果为x=>x.Product.Categary.Type=="1"，测试成功！

回到顶部