浏览 9888 次
|
精华帖 (0) :: 良好帖 (0) :: 新手帖 (7) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2008-03-26
初步设计的一个基于RBAC模型的通用权限管理系统的域模型类图草稿，想用hibernate3或JPA来实现。如下图：
各位看看，给点意见，主要是为了练习一下权限的设计。。 声明：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模型的一个具体实现。 |
| 返回顶楼 | |
