浏览 9897 次
精华帖 (0) :: 良好帖 (0) :: 新手帖 (7) :: 隐藏帖 (0)
|
|
---|---|
作者 | 正文 |
发表时间:2008-03-26
各位看看,给点意见,主要是为了练习一下权限的设计。。 声明:ITeye文章版权属于作者,受法律保护。没有作者书面许可不得转载。
推荐链接
|
|
返回顶楼 | |
发表时间:2008-03-27
For coarse grain permission control, that's it. For fine grain, need ResourceParameter. eg. someboday -> action on -> resource -> with id = 1. However, fine grain control is overkill, since parameters can be unlimited.
|
|
返回顶楼 | |
发表时间:2008-03-27
是比较粗糙的设计。就想从 用户-->角色-->权限(资源--操作的聚合)这方面进行考虑。至于什么用户组(部门),角色的自包含,权限的自包含,资源的自包含都不想考虑。
|
|
返回顶楼 | |
发表时间:2008-07-01
典型的第一级RBAC 用Hibernate或者JPA跟这个有什么关系? 何况,Hibernate和JPA也不是一个层面的咚咚
|
|
返回顶楼 | |
发表时间:2008-07-01
竟然和我自己弄的一样。。。除了个别表名不同
问下Operation表里面存的数据是什么?Resource呢? |
|
返回顶楼 | |
发表时间:2008-07-02
项目中也有这东西 看了你的图有点清楚了
permission 里放的是资源加操作类型么? 比如说 resource里放的是一张桌子 然后Opresion 里放的是增加 删除 然后permission 里放的是 桌子增加 删除这样? 感觉在实际应用中都考虑进去部门这么个概念 就是某个实体应该属于哪个地方 然后 根据部门所在地来 跟角色结合来控制权限.. |
|
返回顶楼 | |
发表时间:2008-07-02
部门就是一个管控范围的概念 这个术语业务逻辑范畴 不用设计到RBAC里面
另外不太明白为什么类图里面会有UserRole这样的关联表?又不是ER图 |
|
返回顶楼 | |
发表时间:2008-09-04
如果在企业应用里,这个设计有点儿太“玩具”了,基本没有实用价值。
比如数据集的概念,授权的概念,资源的分类-例如功能菜单的访问权限以及具体窗体控件的访问权限等等,用户的需求是很复杂的! |
|
返回顶楼 | |
发表时间:2008-09-22
风清云淡 写道 如果在企业应用里,这个设计有点儿太“玩具”了,基本没有实用价值。
比如数据集的概念,授权的概念,资源的分类-例如功能菜单的访问权限以及具体窗体控件的访问权限等等,用户的需求是很复杂的! 如果是企业应用的话,效率上没有特别大的要求,可以整的比较复杂。如果是电信和银行的应用的话,其实我觉得已经比较复杂了。针对个人的应用的话尽可能在满足用户需求的前提下简洁,效率高,可扩展性好。针对企业应用的话,到是可以复杂一些。效率上的提高也是一种很复杂的东西,不是设计关系多就复杂,看你系统要求的并发和响应要求。 |
|
返回顶楼 | |
发表时间:2009-03-11
everlasting_188 写道 风清云淡 写道如果在企业应用里,这个设计有点儿太“玩具”了,基本没有实用价值。 比如数据集的概念,授权的概念,资源的分类-例如功能菜单的访问权限以及具体窗体控件的访问权限等等,用户的需求是很复杂的! 如果是企业应用的话,效率上没有特别大的要求,可以整的比较复杂。如果是电信和银行的应用的话,其实我觉得已经比较复杂了。针对个人的应用的话尽可能在满足用户需求的前提下简洁,效率高,可扩展性好。针对企业应用的话,到是可以复杂一些。效率上的提高也是一种很复杂的东西,不是设计关系多就复杂,看你系统要求的并发和响应要求。 再复杂也是RBAC模型的一个具体实现。 |
|
返回顶楼 | |