由《通用权限设计》而引发的随想

随想

——通用权限 

    起源

    看到园子里有人对通用权限的设计给出了很好的解决方案。但作为一个通用权限设计的悲观者，我还是过份担心中国式的用户需求。总觉得不能太倚靠这样的通用解决方案。虽然这些方案最大化的降低了项目实施人员部署的难度，但却是同步提高了项目权限设计的难度（如果已经使用了第三方的权限解决方案除外）。那我们到底需不需要通用权限设计呢？

    答案是肯定的。当然如果对于一些需求不易变化的小项目，不在我们考虑的范围内。但我上面说了，我是个通用权限设计的悲观者，为什么又肯定通用权限设计的必须性了？下面是我的回答：悲观者不代表不支持，我只是想能有更好的通用权限设计方案。但没有什么事情是绝对的，只是相对于我现在的知识积累，我需要将我此时对通用权限设计的想法记录下来。下面是我对这个方案的描述。

    难点

    通用一词的解释为“公共使用，普遍使用”。这就引发了一个问题：用户的需求无限化，我们不可预知！所以我们这里的通用更准确的描述应该为狭义的通用。但就是这种狭义的通用，就足够我们忙上一阵子了。:-)

    一个想法

    我们是否可以设计一个简单的权限描述语言，通过这个描述语言来灵活的配置系统的权限。

    权限的意思为执行的权利范围。那么谁拥有这个执行的权利呢？一般情况下是人。那么这里需要解决的主要问题就是如何描述人和权利范围之间关系。那么权利范围的范围又是什么？范围在我们软件应用系统中，可理解为一系列原子操作的集合。而对应的原子操作需要针对不同的应用系统来划分。相对小的系统根据系统需要可将原子操作划分得大点，比如：对某个模块的CRUD操作为一个原子，这里具体的如何设计原子操作不做具体讨论。

    那么，到此为止，我们来看一个实际中的权限例子：某个区域管理员只能添加和修改该区域下的指定商场集合中的某种指定的商品集合的商品。这样读似乎有点拗口，实际点这样描述：负责上海区域的一个管理员王五只能添加和修改位于浦东区的家乐福超市中的中华烟和苏烟。这是个比较常见的权限，任何一个老板都可能相出这样或是那样的需求来。那么针对上面的需求，我们分解来看就是：区域：上海，浦东，所有的家乐福；商品种类：中华烟和苏烟。分解看似乎就剩下区域和商品这个简单的限制条件了。具体实现也不是很复杂。但如果对于易于变化的系统而言，实现这些需求需要前期能够最大的预先考虑到未来可能会出现的需求，这样才能在新的需求到来时可最小化的改动代码。

    现在让我们用权限描述语言来描述上面需求，它看起来会像这样：   

     (Add And Update) List("中华烟","苏烟")

     Where (People Or PeopleGroup) in("上海->浦东区->家乐福{All}")

    

    需要帮助 

    设计到了这里，我觉得我的思维一下子被掏空了，头脑一片空白，觉得下面的路设计和论证之路会很艰难。上面的这个描述语言我是参考了SQL。为什么会这样了，原因是我目前的知识结构还只能考虑到这个层面上。设计一个描述型语言不是一件容易的事情。虽然这篇文章才写了一点,也没有论证其可行性，但我希望以后在我知识体系掌握完全了，我再回头论证这篇文章是否可行！ 

 

    园子里朋友，如果您可以的话，也可以帮助我一起求证该实现的可行性或是证明该实现的局部性和不值得性。 

    请允许我放在首页...如果大家觉得不好，我可以撤下！:-)

    End.