权限管理实现思路

[yiyecaodu]

现在我看到的权限管理在代码里实现的思路分为两大类：
1.在代码里按钮等事件的地方添加权限判断。
2.在方法利用特性添加权限管理。
求大神帮忙，回答一下这两种分别更适合哪种情况？B/S？C/S？
还有没有其他权限管理的思路？
现在我想做的是，无论是b/s还是c/s，前端只是做展示功能，后端提供业务，还有一个数据服务层提供数据。
大神有好建议的帮小弟一下。在此谢过啦！

[以专业开发人员为伍]

比如说这样一个伪代码

<button class="menu_item" data-expression="{visible: 当前用户岗位适配('看门人')}">.......</button>

这样一个配置，既是代码也是数据，所以现在许多代码本身就是配置数据，可以随时上传更新到服务器，所以这类就可以写到代码中。 然后假设最终用户给钱，需要开发一个自己喜欢的配置界面，那么你就可以请 UI 设计师单独设计几个页面，并且把上面的配置语句中的岗位“看门人”改为一个从后台取岗位配置的函数！ 所以你问何时采取不同的设计，我觉得“看钱是否到位”。有价值的是做用户 100% 需求符合的 UI，而不是做一个千篇一律的简单的配置界面。

[以专业开发人员为伍]

引用 楼主 yiyecaodu 的回复:

现在我想做的是，无论是b/s还是c/s，前端只是做展示功能，后端提供业务，还有一个数据服务层提供数据。

其实我对你这个说法不置可否，我觉得这其实永远正确但是没有什么具体意义啊。 直截了当地说，许多软件有一个千篇一律的所谓矩阵配置界面，如果你们已经有了，就强行给用户。但是如果你们的订制开发技术非常成熟，能够100%做到用户的UI灵活需求，那么就不要太多的千篇一律的UI画面，而是要少量精确地——用户给钱购买的——的画面就足够了。不要惯用户免费得到一大堆垃圾功能画面，完全可以跟用户谈好了之后再单独拿出2天时间再订制开发一个权限配置画面。 所以不要绞尽脑汁罗列无用的所谓技巧，要想就想大的方面的设计，用户能不用过多思考就掏钱的那些技术实现才值得你去纠结技术问题。

[以专业开发人员为伍]

你会看到，好的设计具有说明性的。例如菜单部分要查询权限、功能接口部分要查询权限，菜单权限可能更本不是纠结于业务 Model 上去声明的而是直接在菜单定义代码上去说明的，不是运行时的代码而是“声明性的”代码........这些总结起来都有同样一个指向，就是要从前端出发。 有的人满脑子只有增删改查，只有数据库表，这个时候连用户 UI 需求都不能忠实地 100% 地快速实现，他只是浸淫在自己的能根据几个数据库表来自动产生增删改查的表格界面的“技术”中，这时候其权限管理，也就是表现在可能知道在 Model 上去配置一下，而抵触那种要到丰富的前边万化的 UI 框架层面去配置一下的做法。 但是假设你的 UI 开发是高速的、需求驱动的、有层次的，那么你应该在这个层面来声明权限，可以把沉重的甚至平常坑用户的一些项目轻松实现。因为用户真正关心的权限理念这样才打通了。

[yiyecaodu]

感谢您的回复。我是这样理解您的回答的：
无论是在代码里直接写‘看门人’，还是通过函数获取权限。这个还是基于前端实现的权限管理。
还有一种实现方式，例如计算按钮，点击计算按钮，调用后端Cal函数时，该函数有一个特性，可以根据当前用户判断是否可调用该函数。这样在前端所有的调用中不会出现‘看门人’等有关权限的代码及函数。

[以专业开发人员为伍]

是的。如果前端框架开发高效、特别有表现力、实时更新部署，那么你的权限就直接放到前端技术层面去设计，这样最符合现代开发理念。

[yiyecaodu]

好的，非常感谢您的回答。

[以专业开发人员为伍]

要避免在那种根本不接触千变万化的前端设计的底层或者Model层来开始声明权限。初学者喜欢从底层数据库表来揣摩用户方的“猴儿精”的领导将来会这么折腾权限和流程问题，结果就会想象什么“万能的”通用权限配置体系，乐死不疲的耗费7、8年大好时光。 实际上当我们把前端开发效率提高了10倍以上，可以随时根据用户需求 100% 地重现灵活界面时，我们发现，仅仅纠结于后台、底层系统的权限设计，没有竞争力！

[以专业开发人员为伍]

函数、数据库表甚至数据库库记录可以不可能层层套权限？我对这个不知可否。 你可以看出来，我是强调新产品推出的效率。所以咱们不把思路聚焦到用户可能不到的地方，先从前端的千变万化的需求改变特性入手，而不是忽视用户折腾界面的需求来花很多时间研究底层数据、函数如何在运行时不断因为权限而阻拦程序执行。可以这么说，一开始过分技术化是个错误的方向。

[qq_3958]

举个例子，以角色权限为例子


管理员表
角色表：数据为-超级管理员 ； 管理员
权限表：数据为-a ；b； c； d ； e（赋权限给管理员的权限）
角色权限表：数据-1 超级管理员 a ；2 超级管理员 b；3 超级管理员 c；4 超级管理员 d；5 超级管理员 e；6 管理员 a；7 管理员 b（这里假设只给管理员两个权限）
管理员角色表：xx 超级管理员 ；xxx管理员

每次添加用户给其绑定角色时，如果是想绑定超级管理员，先查询数据库里管理员角色表中超级管理员有没有已经被绑定给其他用户，没有的话可以绑定，有则提示给前台页面；而想绑定管理员直接绑定，插入管理员角色关系表即可。

[以专业开发人员为伍]

你会发现，“权限管理思路”假设在几个数据库表设计中又绕回到了“权限表”这个概念，而且这个表中的数据是“a;b;c;d;e......”那么你就发现问题了，绕来绕去其实是增加了冗余的一堆概念而没有解决这个权限管理实用化问题。 因为权限往往要直截了当，往往要深入地插入千变万化的操作 UI 设计中。例如一个很小的画面上有20个不同选项，根据权限不同而有一些选项就会消失，或者根据权限不同就要选择不同的控件，那么你在一个数据库中根本不知道千变万化的 UI 设计改变是多么地丰富，你怎么在数据库表中“万能地”设计什么足够聪明的权限管理系统？ 权限管理的实现思路，从前端开始。并且假设你的前端框架足够清晰实用的话，并且代码就像普通数据声明一样地干净简洁的话，那么你在这个带有声明性的前端代码中直接写权限表达式就行了。这样就可以为不同用户设计 100% 地符合他的企业当前价值急需的灵活的 UI 界面设计。 而不是先跑到什么后台数据库中去搞权限。

[以专业开发人员为伍]

你在数据库表中可以很简单地声明“部门、岗位角色、人员”的关系。因为这是静态的规范的简单的表格数据。 但是假设越是接近于复杂的、多变的、无结构的 UI 设计，你越不能纠结于数据库表。

[把分全给哥]

权限管理无非就是判断函数，怎么获取函数参数及怎么实现函数重用

[.NET快速开发框架]

主从结构设计可以参考一下： http://blog.rdiframework.net/article/201 或 https://blog.csdn.net/chinahuyong/article/details/84983243