通用权限模型初探

    在网上收集了很多关于权限讨论的文章，大都是基于RBAC的讨论。
    本人在实际做项目时候也遇到类似权限设计问题。如果是一个模块的话，是比较容易处理的。当系统一大，涉及到得业务越多的时候，麻烦就来了。正如写代码一样，同一个功能，不同的人使用java可以写出千奇百怪的代码来。
    同样仅仅依据角色理论，来指导各个业务模块做权限设计，也会出现千奇百怪的阐述。有没有一个更好的模型或者更加傻瓜化的指南，让所有的业务都可以依据一个简单的判断和固定的套路来解决权限设计上的问题呢。
    基于此问题，参看了一些系统的权限管理界面。总结出了一个四级权限控制模式，或叫做模型。整个模型本身基于角色理论。只是对角色的权限做了一个四个层次的定义。
    这四个层次，和网上有人说的：页面、按钮、数据三个层次有异曲同工的意味。我基本上分为这四个层次：业务模块、业务操作、资源、具体数据（或叫数据对象实例）。也就是说此权限模型是能控制到具体数据的。
    先卖一个关子，具体思路下回分解。

出发点就有问题，理想情况下业务根本不需要知道权限。

的确业务本身不知道权限，但规划的业务的时候是必须知道，哪些是要被受控的。
否则你的内表等信息不做要求，不提供信息，权限想控也无从控起。因为得不到该有的信息。
业务本身不知道权限，这种理想情况，只有出现了固定的开发和设计的模式后。也就是有了
固定的软件模型，例如SAP表单、金算盘的业务单据和一些开发平台的应用模型（认为一个应用由哪些部分构成）。因为这些软件模型，本身就将权限考虑进去了。所以对开发者和设计者，可以不用知道权限的存在。

但在出现自己的平台前，我想一个固定套路可以算是一个积累。

以上是个人看法，如有不妥，欢迎讨论。

我支持这种看法：理想情况下业务根本不需要知道权限

如果把权限逻辑和业务逻辑，在编码阶段不采用专业产品，采用耦合编码模式还可以理解。
如果把权限逻辑的相关数据模型，与业务模型耦合在一起。这点个人不敢认同。

我公司在设计权限的时候，将权限与业务分开，权限数据模型与业务数据模型也是单独存放的。当然，权限与业务紧密关联，因此权限会读取业务数据。反过来，业务不会读取权限数据。

我公司在设计权限的时候，将权限与业务分开，权限数据模型与业务数据模型也是单独存放的。当然，权限与业务紧密关联，因此权限会读取业务数据。反过来，业务不会读取权限数据。
请问，你的权限是怎样读取业务数据的，因为权限相对来说是静的，业务是动的，所以我感觉应该在业务中，权限应该想一个拦截器一样工作。