权限体系解析 功能&数据

权限是所有应用都需要考虑的问题。从方向上来说，权限可以分为功能权限和数据权限，功能权限指你能发起什么事件，数据权限指你能看到哪些数据。合起来就是你能看到哪些数据，对他们分别能发起哪些事件。

功能权限有很多理论模型，经常谈到的有DAC，MAC，RBAC，ABAC，可以看到都是AC结尾，AC代表Access Control。其中以RBAC在实际系统中应用最多。

DAC有两个关键点：1资源默认只有创建者拥有全部权限；2资源由谁创建，该资源的权限就由谁分配；

DAC是这样工作的，系统首先会识别用户，然后根据用户要 *** 作的资源，去查询他是否能做 *** 作，比如查看和编辑。最典型的例子，就是Windows的文件权限控制：

DAC的缺点在于：权限控制过于分散，不方便管理。

MAC有四个关键点：1资源和用户都有权限等级；2资源和用户的权限等级全部由管理员控制；3用户权限等级高于或等于资源时，才具有 *** 作权限；4下读上写。

其中下读上写，是出于保密的考虑。具体是指用户只能阅读权限等于或低于自身的资源，只能创建和编辑权限等于或高于自身的资源。举个例子，权限等级1最低，5最高，用户A的权限是3，他可以看到等级为1，2，3的文件，只能创建和编辑3，4，5的文件。

MAC通常用在保密性比较高的政治军事系统中，比如FBI的文件保密系统。缺点在于太过严格而导致不够灵活。

这是实际应用最多的一个模型。RBAC有几个概念：用户，会话，角色，权限。其中用户角色权限都好理解，而会话其实就是session，可以看做是登录验证通过后的句柄。

这个模型有4个变体：RBAC0，RBAC1，RBAC2，RBAC3，下面分别来看。

这是最简单的，一个用户只能对应多个角色，一个角色对应多个权限。如下图：

RBAC0有个麻烦的地方，当角色A有权限1到10共十个点，角色B有权限1到11共十一个点，你创建角色A之后，创建角色B的时候又为角色B再勾选十一个权限点。

RBAC1在RBAC0的基础上，引入了角色继承。上面的例子，你创建角色A之后，创建角色B时，只用继承角色A然后再另外勾选一个权限点就行了。

角色继承分为普通继承和受限继承。

普通继承 ，是指一个角色可以有多个父角色。利用普通继承，可以做到角色组的概念。

受限继承 ，是指一个角色只能有一个父角色。利用受限继承，可以做到角色的严格树形结构。

RBAC1如下图：

RBAC0还有个麻烦的地方，由于一个用户可以分配多个角色，如果把一个用户同时设置成裁判和球员，就糟糕了。

RBAC2在RBAC0的基础上，引入了责任分离。责任分离分为两种：静态责任分离SSD，动态责任分离DSD。

当给用户分配了球员角色时，就不允许再分配成裁判角色，这是静态责任分离的一种。

可以为用户同时分配球员和裁判角色，但是同一场比赛，用户只能使用一种身份参加，这是动态责任分离。

静态责任分离 的本质是在分配角色时增加约束。约束有三种形式： 角色互斥 ，就像上面的例子，不允许给用户同时分配球员和裁判； 基数约束 ，限制一个用户能拥有的角色数量；先决条件约束，用户要拥有一个角色，必须先拥有另外一个角色，比如必须先成为工程师，才能成为架构师。

动态责任分离 的本质是在系统运行时有所约束。比如用户既是球员也是裁判时，登录系统时必须选择其中一种角色登录，登录后只拥有被选角色的权限。

RBAC2如下图：

RBAC3就是同时实现RABC1和RBAC2，如下图：

ABAC的本质，是根据规则，动态计算一个或一组属性是否满足某种规则，来进行授权判断。通常用来计算的属性分为：用户属性，环境属性， *** 作属性和资源属性。可以用XML，YAML或其他形式来存储规则。

简单来说，就是把访问规则写在配置文件里，当用户要做 *** 作的时候，规则引擎根据配置去计算结果。

ABAC的优点：

1 规则集中式管理。也就是配置文件。

2 可以按需实现不同颗粒的权限控制。意思是配置文件的规则，是自定义的，A模块可以做到菜单级，B模块可以做到功能级。

3 不需要预定义判断逻辑，减轻了权限系统的维护成本，特别是在需求经常变化的系统中

缺点：

1 不能直观地看出用户和权限之间的关系。

2 规则如果复杂，或者设计混乱，会给管理者维护和追查带来麻烦。

3 权限判断需要实时执行，规则过多会导致性能问题。

数据权限，我觉得可以分为三个级别去讲：表级，行级，列级。

作为一个技术员角色，就不应该看到销售数据，这就是表级权限，其实跟前面说的菜单权限是一个意思。

作为基层销售，你只能看到自己的销售数据，作为销售总监，能看到销售部门所有人的数据，就是行级数据权限。从上面这个例子可以看出，行级数据权限是由组织结构决定的。当然 最简单的办法就是硬编码 ，在组织结构里只能看自己和下级数据。优点是简单，缺点是不灵活，无法处理跨节点看数据的问题。

另一个办法就是配置用户和组织结构的关系，下图是一个例子：

像上图所示，把角色跟组织机构关联起来，也就间接把用户跟组织结构关联了，你就知道谁官大谁官小了，同一个数据表，村长能看自己村的，县长能看十几个村的。

也可以直接把用户跟组织机构关联起来，做起来简单，但是调整的时候偏麻烦一点。

如果给角色分配组织结构，可能会造成角色承担过多责任。如果直接给用户分配组织结构，可能会造成调整麻烦。于是我们可以引入岗位的概念，通过岗位把用户和组织结构关联起来。

以上就是通过组织结构解决行级数据权限的方法。其背后还存在一个问题， 一个用户可以同时站在组织结构的多个节点上吗？ 通俗的说就是，一个人可以同时是村长和县长吗？如果可以，他能看全县所有村的数据吗？

这个问题要看实际业务情况来定。如果不能兼任，就不存在这个问题了。如果允许兼任，数据权限就应该取并集。

我们假设一个不太严谨的场景，销售数据包括销售员，客户信息，合同编号，金额，提成。销售总监，可以看到销售部门所有销售数据，但是提成这一列是看不到的。这个场景就是列级数据权限。

当然最简单，还是硬编码 。写死某些角色就是看不到某列数据。同样，优点是简单，缺点是不灵活。

引入一个概念，数据资源，说白了就是数据表，数据资源包含表里所有字段。接下来就跟行级权限处理一样了。

最近在做一个业务管理系统CRM，期间也是激发了不少思考和沉淀。B端系统的底层基础模块之一是权限管理，而RBAC作为目前使用最为广泛的权限模型，我认为有必要单独研究整理一番。本文将从RBAC的定义、RBAC组成、3个安全原则、4种模型和RBAC基础产品功能模块进行介绍。

一、什么是RBAC

RBAC，基于角色的权限访问控制（Role-Based Access Control）。RBAC通过定义角色的权限，并对用户授予某个角色从而来控制用户的权限，实现了用户和权限的逻辑分离。通过对用户设置角色，对角色设置权限范围从而使得不同用户拥有不同角色对应的权限。这样的权限设置十分清楚，也极大地简化了权限的管理，管理起来十分方便。

二、RBAC组成

在RBAC模型里面，有3个基础组成部分，分别是：用户、角色和权限。本质上是用户与角色的映射、角色与权限的映射。

名词解释：

User（用户）：每个用户都有唯一的UID识别，并被授予不同的角色

Role（角色）：不同角色具有不同的权限范围

Permission（权限）：访问权限

用户-角色映射：用户和角色之间的映射关系

角色-权限映射：角色和权限之间的映射

三、RBAC的3个安全原则

 RBAC三个安全原则：最小权限原则、责任分离原则和数据抽象原则

最小权限原则：将角色配置成该角色完成某项任务所需要的最小权限集合。比如客服人员，所设置角色拥有的权限仅限于其能够完成客服相关任务的权限范围。

责任分离原则：通过设置相互独立互斥的角色来共同完成敏感的任务。

数据抽象原则：通过权限的抽象来体现数据的抽象。比如财务人员 *** 作借款、存款等抽象权限，而不是使用 *** 作系统提供的读、写、执行等具体的许可权。但RBAC不强制要求这原则，安全管理配置RBAC模型时可以允许不遵循该项原则。因此，支持数据抽象原则的程度与实现细节相关。

四、RBAC的4种模型

（1）RBAC0

最基本的RBAC模型，也是BRAC的核心思想。即用户和角色是多对多的关系。一个用户可有多个角色，对应多种权限。一个用户至少有一个角色。一个角色至少有一个权限。

例子：部门经理可以同时是项目经理和架构师。

（2）RBAC1

在RBAC0的基础上进行了角色分层，一个角色可以从另一个角色继承许可权。

例子：在一个公司销售部门中，分有区域经理、城市经理、销售人员。此时，我们可以运用RBAC1的分级模型，将销售这个角色分为多个等级，赋予不同等级的不同权限。

（3）RBAC2

增加了约束模型，添加了部分限制。强调在RBAC的不同组件中在配置方面的一些限制。一般设置的限制我们有以下种类：

1、互斥角色限制：即字面意思，同一个用户在不同互斥角色中，只能选择其中一个；

2、基数限制：一个用户拥有的角色是有限制的，一个角色拥有的权限也是有限的。

3、前置条件限制：一个用户需要获取更高一级的角色，前提是已经拥有低级角色。

4、动态限制用户与角色：即一个 用户可以拥有多个角色，但账号运营时只能激活使用一个角色。

例子：一个公司的销售经理可以分配其销售经理的角色，但不能再分配合同审核的角色。否则将会出现一种场景为销售经理创建合同，同时又自己审批了合同，这是不允许的。

例子：在销售人员-城市经理-区域经理的晋升路径上，一个公司的销售人员，要晋升为区域经理，首先要先成为城市经理。

（4）RBAC3

我们可以这么理解，RBAC3是基于RBAC0的基础上，RBAC1与RBAC2的集合统一，即RBAC3=RBAC2 + RBAC1，称为统一模型。

五、RBAC基础产品模块

在实际需求的产品功能设计中，涉及的功能很多也很多样，概括出来几个模块一定包括用户管理、角色管理、权限管理三个模块。每个模块也包括增删改查几个部分。业务主流为：

1创建权限

2创建角色，并关联权限

3添加用户，并为用户设置角色

六、后记

文章的内容主要从工作中实际遇到的场景中进行总结概括，更多的是提炼其方法论精髓。后续有机会将结合理论与详实的案例来和大家做更多的分享与交流。

AI-product，产品人的聚集地  回复“区块链”，获取整理好的区块链资料汇总。

回复“思维导图”，获取100本书思维导图。

    几乎所有的管理后台都会涉及到权限的设计，权限控制是管理后台的重要功能，可以有效的提高系统的安全性，减少误 *** 作、数据泄漏等风险的发生。但是，很多产品经理会对权限功能有一点害怕的心理，一方面是由于能参考的实例较少，权限管理算是一个“系统级”的基础功能，一般系统中只有管理员可以 *** 作，不像其他功能可以通过去其他系统中试用体验，另一方面，对于权限功能普通用户无法 *** 作使用，所以存在感较低，做好了也不会出彩，可没做好就会导致整个流程不通、产品崩溃。

一 RBAC 模型

    目前，接受度较高的功能权限模型是RBAC（Role-Based Access Control）模型。在RBAC中，权限与角色相关联，用户通过成为适当角色的成员而得到这些角色的权限。这就极大地简化了权限的管理。在一个组织中，角色是为了完成各种工作而创造，用户则依据它的责任和资格来被指派相应的角色，用户可以很容易地从一个角色被指派到另一个角色。角色可依新的需求和系统的合并而赋予新的权限，而权限也可根据需要而从某角色中回收。

1角色的作用

如果没有角色的概念，直接用户对应权限，虽然会更加灵活，但是后台的数据表设计会变得复杂， *** 作成本也会很高，同时容错能力也会变得很差。

而引入“角色”概念后，用户与角色可为多对一或多对多的关系，当一个用户的角色为多对多时，当前用户的权限是多个角色的并集。此时只需要为角色赋予权限，能够大大减轻管理负担，同时将用户与权限解耦，提供更大的灵活性，同时整个设计的容错能力也提高了很多。

2引入用户组

   一些大型的平台上，如果用户数量较大，新增角色时，需要为大量用户分配新的角色，工作量巨大，此时可以引入用户组的概念，将这些用户拉到同一个用户组中，然后对整个用户组进行角色的指定，这就大大减少了角色分配的工作量。

同理如果权限较多时也会存在一样的问题，对角色进行权限设置时也需要大量的 *** 作，此时可以考虑引入权限组的概念，将关联性较强的权限大包成组赋予角色，从而减少赋值时的工作量，现实中权限组的使用相对较少，因为系统中的权限一般来讲是有限的。需要注意的是即使有用户组或权限组的存在，也可以允许用户或权限与角色直接关联，这个可以视具体业务情况而定。

下图所示为mac系统中运行添加用户组，并以用户组为单位配置权限。

3 角色继承的RBAC模型

在一个业务场景中，如果角色需区分：设计主管、设计组长、设计成员，并且管理方式为向下兼容时，则需使用角色继承的RBAC模型。上层角色继承下层角色的全部权限，且可额外赋予权限。

此时除了对角色进行定义，还需要管理角色间的关系，通过关系来体现角色的层级关系，从而达到继承权限的效果。角色的继承关系主要有两种：树形图和有向无环图。

继承关系常常来源于公司团队的组织结构，此时常将角色与组织结构进行关联达到继承角色模型的效果。如下图所示的赵同学，其角色是“三级团队负责人”，与其并列的小组中有多个“三级团队负责人”的角色，但依附于左侧的组织结构树，各级负责人仅有查看和 *** 作自己下属子节点的权限。

4 限制的RBAC模型

在一个产品或系统中，部分角色可能是需要隔离的、不允许被同时赋予一个人的。跟大家熟知的“不能既是‘运动员’又是‘裁判员’ ”一个道理。

因此，对于众多角色中的一组，只能是单选的关系，但多组角色之间可以共同存在。如下图中，一个用户可以既为设计师又为管理员，但在设计师角色组中仅能被赋予一个角色，在管理员角色组中也仅能被赋予一个角色。

此外，限制还有可能是数量上的，比如一个产品组中必须有且只有一个管理员，不允许删除或再分配管理员角色，仅允许将负责人角色变更。

限制的模型不仅仅对分配过程产生影响，有时即使拥有了多种角色，因为不同的角色对同一个功能的使用方式或数据会产生冲突，所以使用时也需要进行限制。如下图所示为同一时间仅允许以一个身份登录。

根据不同的业务需求，限制的形式很多。需要注意的是不能仅依赖后端限制，而是要在前端展示清晰的规则和恰当的限制，避免用户出错和沮丧。

三、权限的拆分与设计

通过RBAC模型已经能够很好的搭建起用户、角色与权限之间的关系了。但具体是什么样的关系，以及“权限”这个抽象的概念具体如何规划？

这些都需要分析清楚才能进一步设计出完善的权限系统。

首先需要知道，一般产品的权限由页面、 *** 作和数据构成。页面与 *** 作相互关联，必须拥有页面权限，才能分配该页面下对应的 *** 作权限。数据可被增删改查。

整体关系如下图所示：

因此，在设计之初我们就需要考虑到未来可能区分角色的地方，尽量解耦、模块化。对于技术来说，每一个页面模块、每一个 *** 作都最好使用独立的接口。对于设计来说，需要保障所有角色因为权限而屏蔽掉部分 *** 作和数据后，页面和流程仍能体验流畅。

保证初期设计支持后，配置权限时，还需要注意以下几点：

（1）确定是否支持前端配置

如果角色和权限相对固定，则一般将角色与权限的关系可以写在后台，改动时需要后端变更且重新上线。这种情况适用于公司内部系统等只有一个使用主体的系统。

如果需要自定义角色或者每个角色在不同使用者的场景下有不同的权限，则需要将角色的定义、角色与权限之间的配置体现在“前端用户配置页面”。这种情况适用于有频繁变动的自定义角色权限，和有租户体系的系统。

（2）以基本单元拆分，以业务逻辑配置

一般可将每个对象的“增、删、改、查”各自作为一个基本的权限单元。打个比方，在“人员管理”中，查看人员列表、添加人员、删除人员、编辑人员信息最好拆分为4个权限单元。在技术和设计上，我们希望能尽量做到解耦和模块化。

但是在业务层面有些 *** 作却是一体的。这些不能拆开的权限在“前端用户配置页面”中建议打包成一个整体提供配置。例如：如果我们确定在系统的现有和未来业务中，仅分为普通成员有“人员管理”的查看权限，管理员有 *** 作权限，则可将“增、删、改”三个基本权限单位合并为“ *** 作”权限进行配置。

（3）页面权限优先于 *** 作和数据权限

必须配置了页面模块权限后，才能配置当前页面模块下具体的 *** 作权限，以及页面模块的数据展示权限。

（4）查看权限优先于增删改权限

正常情况下，一定要先能查看某个模块或 *** 作，其它的增删改 *** 作才有意义。因此在设计时，应在获取查看权限前限制其它权限的配置，或者配置其它权限时默认赋予查看权限。

（5）角色与权限的多种关系

角色与权限的关系不仅是单纯“是/否关系”，还包括以某种限制进行 *** 作，和以某种程度访问数据。

例如在“人员管理”中：

数据范围：用户拥有查看人员列表的权限，但仅能查看自己所在的团队；数据边界限制（上限等）：添加人员时不能超过20个等。数据字段：HR能查看人员列表中包括职级、薪资等字段，其它角色仅能查看姓名邮箱等字段；

（6）角色与权限的设计表达

在传达一个系统的权限设计规则时，设计师常常习惯用主观最直接的方式表达想法，如用“当……时，就……”的句式来表达。但一个平台中涉及的权限规则是非常多的，当通篇以这样的形式描述时，表达对象将很难理解。

正确的描述方式：更清晰的是基于开发的语言，和技术模型的结果进行表达。将各角色与权限单元绘制成网格，每个交叉点网格中描述该角色与权限的数据关系和限制。

如下图所示：

四、需要注意的Tips

1 隐形的admin

在可自定义角色和权限的系统中，一般需要预留一个admin角色来进行系统的初始配置，用于添加首批的业务人员和配置基本的角色。

有的系统中允许存在上帝视角的admin角色，则其可以作为“超级管理员”显示在角色配置的列表中。有的系统中不允许这种角色存在，则可将这种角色设置为隐形的状态，仅赋予维护系统的工作人员。

2 初始权限的赋予

对于允许用户自行加入的系统，需要设定一至多个默认的角色，有时可以是仅有最基础权限的“游客”角色。

初始权限还可以与用户既有的某些数据字段进行关联，如添加用户时获取到用户的岗位为“设计师”，则直接赋予“设计师”角色的权限。

3 人员管理中对自己的处理

在人员管理中，管理员角色处理自己时需要额外注意。因为如果修改或删除了自己角色后，可能导致系统没有管理角色，从而无法添加其他成员和正常运行。设计时可添加判断，当自己为唯一管理角色时，禁止编辑和删除。

4 无页面权限的提示

虽然可以通过页面权限限制直接隐藏当前用户没有权限的页面，但不能排除用户获取到权限外的url地址。当用户意外访问到没有权限的页面时务必提供“无权限”的提示，避免用户认为系统bug。

最后

总结一下，整个权限系统设计就是定义各个节点和节点间关系的过程。

节点包括：

用户；用户组；角色；角色组；权限（页面、 *** 作、数据）；权限组（页面、 *** 作、数据）；

关系包括：

是/否关系；继承关系；限制关系（互斥、范围限制、边界限制、字段限制……）

Openbiz Cubi PHP开发框架

这显然是一个高耦合性的框架的代表，有点让开发人员“拎包入住”快捷酒店一样的的感觉。Openbiz Cubi 是一个应用平台式的开发框架。虽然与众多更加耳熟能详的框架相比 Openbiz Cubi 仍然是一匹黑马，但是还是一个十分值得推荐的框架。它自身基于Zend Framework构建，但是拥有自己独特的基于元数据的 MVC 和 ORM 逻辑，并采用Smarty和PHP模板 作为主要UI的模板引擎，所以如果你是Zend框架的玩家，别担心，Openbiz Cubi的代码也会同样让你很容易上手。

它不同于其他传统意义上的PHP框架，它具有一个类似JAVA的元数据引擎， 可以通过XML的方式来“描述”大多数对象，甚至通过XML的描述就可以实现数据的CRUD（增删读改）这些 *** 作。如果你的业务需求仅仅是要实现一些简单 的数据CRUD *** 作，你甚至不需要去写什么PHP代码，XML就可以全部搞定。而你的PHP功夫可以通过他的Plugin-Service方式用于集中在 实现某些特殊的业务逻辑上。

Openbiz Cubi目 前还有一个叫做 Openbiz Appbuilder 的超级好用的代码生成工具，对于还不熟Openbiz的XML元数据的开发人员来说，Appbuilder 绝对是一个可以帮助你快速上手的利器，他通过图形界面的生成向导来帮你自动创建数据对象、表单对象、嵌入式服务，甚至整个应用程序的雏形。 按Openbiz的官方介绍来说，你只需要思考清楚你的应用程序的业务逻辑，剩下的代码工作就交给Openbiz Appbuilder来帮你搞定吧。

CakePHP 开发框架

如果你仍然需要编写面向PHP4兼容的代码，CakePHP 将是一个非常不错的选择， 在PHP 4 & 5的MVC式框架列表里面，CakePHP都曾经是最流行的。它还提供了很多种途径的技术支持（讨论组、留言板、IRC等）还有优秀的教程。 CackePHP是个很容易上手的框架，但是你并不容易在短短几周的时间就完全掌握它。

Zend Framework框架

Zend Framework 是面对一些较有经验的开发者和从底层构建一些企业级应用程序而设计的。（例如：宣称面向企业应用而设计的 Openbiz Cubi 就是基于Zend Framework框架之上而构建的。）该框架是高度模块化的。这意味着你可以按你的实际需要来引用Zend的代码。有些函数库甚至可以很容的被提取出来 单独使用（例如Zend_Gdata，这也是个低耦合性的特点）使用Zend框架，你不必非要遵从它的MVC架构，（虽然你最好能这么做），并且它还提供 了许多内建的高级功能用于完成与现有的web服务整合，多语言化和实现单元测试这些任务。

CodeIgniter

CodeIgniter 是一个PHP52+ 的MVC框架，它体积小巧切具有丰富的文档资源。通常被称为“初学者框架”，因为它相对容易试用和较短的学习曲线，此外CodeIgniter也是十分灵 活和强大的。该框架拥有一个非常庞大的社区支持。并且在社区里面很容易找到大量的CI函数库，你可以大胆的梦想， 也许你正需要做的事情在社区的某个交流，某个人已经把它实现了。

Symfony

Symfony 是最古老的PHP框架之一（相信你从他的网站风格上也发现这一点了），他同样也是转为企业级Web应用程序而设计的。然而，对于他所能提供的所有动力和性 能而言，它只拥有很小的体积并且非常容易配置在大多数php的主机环境中。由于他的年头最长久，你会很容易找到许多关于Symfony的教程、书记等资 料，对于新手来说，这绝对是件好事儿。

Symfony使用命令行代码生成工具来为项目快速生成所需的代码，这种方式也许对于某些开发人员来说是前所未闻的（在那个年头，也许 吧。。。）然后，他可以帮助你在很短的时间里完成代码并是他们可以运行。Symfony的网站上手机了大量的教程和范例代码，来帮助你熟悉掌握他们。

Yii Framework

Yii 是一个高度模块化，高性能的PHP5框架，专门为了Web应用程序而开发。Yii采用了大量的命令行生成工具，让你可以快速的生成一些代码，因此，他最适 合于喜欢在命令行的黑窗口上敲敲打打的人。所有这些代码生成工具意味着你需要记住更多的命令和参数，但是一点你做到了，你会发现，它们将大大减少你所要花 费的时间来设置和配置你的应用程序。

这种开发方式 非常类似于Openbiz Appbuilder所提供的向导式的代码生成方式，最大的不同点是Yii是基于命令行去生成代码，Openbiz Appbuilder是在图形界面上生成代码。

ThinkPHP

ThinkPHP是一个免费开源的，快速、简单的面向对象的轻量级PHP 开发框架，遵循 Apache2 开源协议发布，是为了简化企业级应用开发和敏捷WEB应用开发而诞生的。借鉴了国外很多优秀的框架和模式，使用面向对象的开发结构和 MVC 模式，融合了 Struts 的 Action 思想和 JSP 的 TagLib（标签库）、 RoR 的ORM映射和 ActiveRecord 模式， 封装了 CURD 和一些常用 *** 作， 单一入口模式等，在模版引擎、缓存机制、认证机制和扩展性方面均有独特的表现。

Yii Framework

Yii是一个基于组件的高性能PHP框架，用于开发大型Web应用。Yii采用严格的OOP编写，并有着完善的库引用以及全面的教程。从 MVC，DAO/ActiveRecord，widgets，caching，等级式RBAC，Web服务，到主题化，I18N和L10N，Yii提供了今日Web 20应用开发所需要的几乎一切功能。事实上，Yii是最有效率的PHP框架之一。

Yii是一个高性能的PHP5的web应用程序开发框架。通过一个简单的命令行工具 yiic 可以快速创建一个web应用程序的代码框架，开发者可以在生成的代码框架基础上添加业务逻辑，以快速完成应用程序的开发

phalcon

Phalcon是一套实现MVC架构的高性能PHP应用程序框架。初始版本发布于2012年11月，开放源代码并基于BSD授权条款。与其他大部分的PHP框架不同，Phalcon是以扩充的方式以C语言所编写，因此Phalcon的执行速度高过其他PHP框架，并且消耗更少的资源，根据官方的测试，Phalcon是目前世界上速度最快的PHP框架之一。[1]

以上就是关于权限体系解析 功能&数据全部的内容，包括:权限体系解析 功能&数据、产品经理必须掌握的权限模型、系统权限功能的设计等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！