虽然RBAC里，不对用户直接赋予权限，但是我们国内的小公司，特别是
7-8个人的小公司用的软件，基本上都是没严格的岗位之分，领导也只 是很明确的指出，到底谁有什么权限，哪个人可以干啥啥等，一般也急 急忙忙，直接给用户设置权限就可以了，这虽然是错误的做法，但是很 符合国情，不这么做吧，软件还的确有些不好用。我们大部分人开发的 都是底端的小型管理类软件，所以，一般是该用户有什么权限是首先进 行判断的，这样程序的运行效率也会高一些。接着是传统的，这个用户属于哪几个角色，这些角色是否有相应的权限，
这是符合RBAC的体系，也能适应大型管理类软件的权限设计惯例。我的权限判断顺序为：
1. 该用户是否有效的？是否已经被锁定了？
2. 该用户是否为 Administrator 特殊用户？ 3. 该用户是否在 Administrators 特殊角色里？ 4. 此判断权限项是否有效？ 5. 该用户的用户权限关系是否有效？该用户是否有这个权限？ 6. 角色是否有效？ 7. 角色拥有的权限是否有效？ 8. 该用户是否在有效的角色里？当然以上的判断会封装在一个函数里，判断函数越早结束越好，当然不
是非要把这个7个步骤都判断完，那函数的运行效率太差了。为什么这里都判断个有效呢？
主要是为了采用用户主动可以申请权限的做法，例如权限都管理员配置， 那也是很琐碎的工作，用户自己可以申请拥有哪些权限，这些权限申请 被递交上来后，相应的管理员进行审核，审核通过后所申请的权限就生 效了，当然也可以帮别人申请权限，那就灵活性更强了。直接删除数据与是否有效的差别为：
例如一个人以前过过某个权限，现在暂时没有这个权限了，你直接删除
了，虽然省事了，但是数据没有了，过了段时间想恢复权限时，还需要 加上去，这时我的做法时，不是非要删除的数据吧，别非得删除，能打 个有效无效的标志就可以了。不知道我这个想法是否正确，若不正确， 请指点批评。导读：
大恶人吉日嘎拉之走火入魔闭门造车之.NET疯狂架构经验分享系列之（一）后台控制逻辑代码部分
大恶人吉日嘎拉之走火入魔闭门造车之.NET疯狂架构经验分享系列之（二）后台服务代码部分
大恶人吉日嘎拉之走火入魔闭门造车之.NET疯狂架构经验分享系列之（三）商业逻辑代码部分
大恶人吉日嘎拉之走火入魔闭门造车之.NET疯狂架构经验分享系列之（四）高效的后台权限判断处理
将权限管理、工作流管理做到我能力的极致，一个人只能做好那么很少的几件事情。