6. 当事人权限

连载之16

原创：胖子刘（转载请注明作者和出处，谢谢）

6.       当事人权限

书接上文，在这里占用一点篇幅，描述一下目前比较常用的“基于角色的权限控制”设计方法。如果有人有更好的设计，欢迎提供。

“基于角色的权限控制”，核心思想是将权限控制通过当事人所属角色来实现，当事人本身并不直接绑定权限。有关当事人直接绑定权限的设计，不在本文的描述范围之内。

设计思路都是这样的：首先在系统开发时登记注册所有功能模块及代码，系统运行时由系统管理员来维护角色列表、并为每一种角色设定可访问的模块（角色和模块相关联）。业务人员登录系统后，系统递归读取当前用户所属的全部角色，并再次递归读取这些角色能够访问的所有模块资源、形成一个模块代码列表，存储为CS系统的全局变量或者BS系统的Session。每当用户试图进入一个功能模块前，系统都判断一下当前模块代码是否包含在“模块代码列表”中。如果包含，判断其是否存在“拒绝”属性，“拒绝”优先于“授予”。如果没有“拒绝”属性，只有“授予”属性，说明该用户有权限，允许进入；否则，说明该用户无权操作此功能模块，程序给出权限不足的提示，并退出。以此实现权限控制。

设计图如下：

上文还留了个关于“饮食”的小尾巴，现在补全^_^

一段时间以来我总在想，我们中国的饮食文化源远流长，中餐馆遍布全球，为什么就没有一家类似肯德基、麦当劳一样驰名世界的饮食品牌呢？

答案是：我们中国的菜肴不能量产、饮食文化过于强调品种和花样，而且，越是高档的珍馐美食，其烹饪技术越是复杂，越是依赖于某个特定厨师个人的烹饪能力！

这种现状非常不利于美食的广泛传播。有许多美食都是独此一家、别无分店。你对某道菜有好感，只能到他店里去吃；别的饭店即使有同名的菜，味道也肯定不一样。对于食客来说，即使是王母娘娘的蟠桃盛宴，如果很难吃到，时间长了也就失去了兴趣；对于饭店来说，品种越多、烹饪技术越复杂，就越不容易量产。厨师个人的能力终归是有限的，即使是“食神”，他一天又能做几道菜？又有几个人能品尝到？又会有多少口碑？又如何流传世界？

反观肯德基、麦当劳，一共就那么几样食品，但全都是机械化生产，有严格的生成工艺和标准，经过培训后的“厨师”（我觉得还是叫机器操作员更形象一些）做出来的食品，其样式、外观、口味全都一样，随便到哪个城市的哪家分店都能享受到相同的体验。

纵观流传世界的品牌，如可口可乐、百事可乐、肯德基、麦当劳、Windows操作系统……共有的特点都是品种少、可量产。

国内餐饮界符合“品种少、可量产”标准的，个人感觉当属沈阳的“四季面条”。我原来住在沈阳市东陵区的泉园小区（我3年前搬来北京），小区附近就有一家“四季面条”，很符合我上面所说的标准。不但是饭店经营的品种，就连饭店本身都可以量产！一段时间以来我一直有一个想法，就是把沈阳的四季面条开到北京来，按照我的思路有朝一日当可开到全中国、乃至全世界。可惜，个人有限的资金都给房贷做贡献了，不知何时才能得偿所愿！

闲言少叙，本章《通用数据库模型分析》的第一部分——“人与组织”到此结束。

做个预告：本章第二部分将重点讲述“产品”模型，第三部分是“订单”、第四部分是“销售发货”、第五部分是“采购”，第六部分是“财务”，敬请关注。