综合大家的讨论，晓冰在其博客Common Library 菜单控件提出了9点基本需求和实现方式， 另结合实际应用，我加上下面两点：
10. 支持一个User多个Role
11. 实现基于11.的Function级别的权限控制
下面是数据库设计图：
上述6个表说明如下：
1. tbl_ComLib_Menu
该表在上次讨论中已经和大家见面了, 不多唠叨。需要注意的是：指定Active为false的时候，请确保其所有孩子都是false。
2. tbl_ComLib_User
很显然， 这是一个用户信息表，没什么需要说的。只列出了几个常用字段，大家可以扩展。
3. tbl_ComLib_UserRole
存储用户角色基本信息，有两个新鲜的字段：‘HomePage' 和’Priority'。‘HomePage'指的是用户角色在登录系统的时候的默认页面，由于我们实现了一个用户可以有多个Role，所以这里的’Prilrity‘就有用了， 指定那个Role优先级别高。比如登录的时候，进入优先级别高的Role的‘HomePage'.
4. tbl_ComLib_UserRoleUserAssignment
用户和Role的关联表。很简单，就两个字段，存储用户和Role的映射关系。
5. tbl_ComLib_UserRolePermissionFunction
Role和Menu的关联表。(也就是MTR项目里常用到的tbl_RoleRight表， 只是换了个马甲而已）
需要说明的是：
1. 数据除了可以继续像之前MTR项目一样，所有的Menu item都必须关联到Role, 也就是说如果menu中有10条数据，有2role， 则该表有10*2 = 20条数据，如果有访问权限的话， Active设置为true, 否则设为false(这是之前MTR项目的做法). 如果要新加menu， 则该表也为每个role添加相应的menu。
2. 也可以只存储有访问权限的数据， 也就是说该表中只存储有访问权限的数据(当然Active字段也可以去掉了)。我想这种方法存储过程会复杂点， 要找出该记录的所有父亲节点(好的是SQL2005之后可以用WITH temptbl 递归找父亲)。
现在Demo用的是第二种方法，只给Role指定有权限访问的数据， 且只要指定叶子节点即可。 如果所有的Role都有访问权限的叶子节点则不需要在该表中配置记录，默认所有Role都是有访问权限的(用*表示). 也就是说如果该表中一条记录也没有， 默认所有Role对所有Menu都有访问权限。但是现在有一个问题：如果新加一个menu， 且没有配置任何权限在permission function表， 但是该menu的parent 配置了权限， 比如配置了SYS-ADMIN, 但是没有配置给GENERAL, 这个时候， 用GENERAL登陆， 则是给GENERAL添加parent menu的权限？还是不给呢？如果不给的话， 新加的menu会找不到parent而抛出异常。从功能上好像应该给GENERAL添加parent menu的权限， 但是从权限控制的角度， 也就是说用户信息保密的角度，应该不添加该parent menu. 大家认为该怎么处理呢？
6. tbl_ComLib_Resource
Common Library示例menu的title和description存储在resource file
如果有需要将Menu的多语言数据存储在数据库中，则可以存放于该表中， 可以通过简单修改存储过程实现， 其他多语言数据也可存储于该表，如label等, 然后用ResourceProvider事先多语言， 这是下一个Common Library工作项。实例数据如下：
不确定的地方，请留下您的宝贵意见：
1. 数据库表，字段命名规范
2. tbl_ComLib_UserRolePermissionFunction有提到两种数据方案，如果有其他更好的当然更好。
3. Menu的多语言数据是放在数据库还是resource file?
如果有不一样的想法希望您能留下宝贵想法和意见。这只是个初稿， 且有些想法也没有确定，Common Library的建设需要您的一份力量。
另提点意见： 我们的博客真的不太好用1. 太慢了， 图片加载要等。 2. upload图片很不爽， 要刷新页面，也要等。 3. 最不爽的是编辑不太好使。可能是我发帖太少，还没习惯吧。也或者大家都是先在word写好再paste到这里发布， 也或者用email发布， 所以感觉不到这些问题。
Subscribe