我想建立一个分层角色库访问控制。这是我当前的架构：
目前我有两种选择来构建这个系统：
将所有必需的权限附加到角色（非分层）
仅附加特殊的“级别”权限并继承具有较低级别的权限
有更好的方法还是仅取决于我的项目需求？
我倾向于选择分层的，只是因为简单。如果我这样做，有没有更好的方法来选择权限级别，也许使用二进制数？
选项 2 会有一些角色级别，我会有一些权限级别编号。因此，当我创建一个角色时，Full Administrator该角色将继承所有其他权限，因为那将是 4 级，而其他权限的数字将小于 4 级（或 4000）。
这是矫枉过正吗？
我建议使用“方法#1”的变体——非分层角色。
我曾使用过类似的系统并取得了巨大的成功。虽然起初这种方法可能看起来“结构较少”，但它相对简单且非常灵活；当允许每个用户拥有多个角色并定义聚合权限的规则时。
像“OO 层次结构”一样，使用角色层次结构会导致严格的替换关系。这使得根据不断变化的需求定义角色变得更加困难。
例如，将来可能需要一个不能创建自己的帖子的“管理员”帐户。层次结构（及其具有的替代关系）在不改变树结构本身的情况下防止了这种情况，因为“完全管理员”是“付费用户”。
在 SQL 中，针对真实层次结构的查询更为复杂；特别是在不支持递归查询的实现中，比如 MySQL。使用嵌套集或物化方法切换到层次结构会强制在父子关系上使用额外的结构。
你只是不需要它；越复杂的软件就越难编写和维护。虽然在某些情况下层次结构非常好 - 例如材料清单或家谱或目录结构 - 在大多数角色/组权限模型中根本没有“需要”。
没有“父类型”依赖的角色，其功能更像“OO 接口”——好吧，如果要扩展类比，也许Trait 组合会更合适。每个角色的实现（阅读：授予权限）可以独立于任何其他角色进行更改，使其非常灵活。和接口一样，可以将多个角色分配给给定的用户/实体。
在 SQL 中针对平面User <M-M> Role <M-M> Permission模型的查询要简单得多（有或没有递归支持或附加结构），因为根本没有要遍历的角色层次结构。
Windows ACL 组（让我们忽略嵌套组）的工作方式与角色非常相似；用户属于一个或多个授予（或拒绝，但情况不同）权限的组。
我推荐并在上面暗示过的变体是允许跨角色聚合权限。一个简单的聚合模型是这样的：
用户拥有来自他们分配的所有角色的权限的联合。
（有效权限一般会在授权期间建立，但没有层次结构，在 SQL 中查询也相对简单。）
因此，权限是按角色绑定的，很少或没有重叠，如“方法#2”所示，但有以下区别：没有层次结构。
例如，为了允许可以搜索帖子（并删除“坏”帖子）的特殊管理员，只需分配“基本用户”和“受限管理员”角色1。
使用非分层的多角色系统可以清晰地实现这一点，摆脱层次结构的负担，同时仍然提供灵活/可组合/可配置的角色原型。
1这不是一个特别好的例子。实际上，角色应该有不同的名称（例如“帐户支持”或“内容版主”）并涵盖不同的权限集；这些可能会根据试错法和当月的业务规则随时间而变化。
虽然我反对这样的层次结构，但在更复杂的系统中，可能需要允许角色之间的关系，主要是为了对此类进行分组。这种关系通常应该独立于为其他管理目的而存在的有效许可。