用一个简单的B2C的网上商场来说,分了3个子系统实现的。

   1)前台购物网站:实现用户在网站上购买商品的动作,与用户的交互部分。

   2)后台配置管理网站:实现网站后台的商品管理、价格管理、订单管理等等管理配置功能部分。

   3)系统配置管理工具:信息系统管理员用的,用来配置整个系统的权限配置,参数配置、数据字典管理功能部分。

 

   这里会有这样的需求产生:

   一个普通的网站客户:他只能登录前台网站,但是不能登录后台管理、系统配置管理工具,虽然用户密码都是对的,也是整个系统的有效用户,但是不允许登录后面的2个系统。

   公司的一个职员(员工):他可以登录后后台配置管理网站,同样他也可以购买自己公司的商品也可以登录前台购物网站,当然没必要搞2个账户吧,就用一套用户名、密码就可以了,但是这个员工未必可以登录系统配置管理工具。

   公司的信息主管:他允许登录任何系统,当然也允许信息主管购买自己公司的商品,当然也用一个账户就可以了,没必要搞3个账户出来,可以充分体现一下我们的设计水平。

 

   解决问题:

   1:前台购物网站:只要用户名、密码对了,账户没挂失、没被锁定的,都可以登录,说白了,是用户就可以登录了。

   2:后台配置管理网站:不仅仅是用户名、密码要对,还需要有权限"Shopping.Admin.Access"权限才可以,登录时需要判断。

   3:系统配置管理工具:不仅仅是用户名、密码要对,还需要有权限"DotNet.Admin.Access"权限才可以,登录时需要判断。

 

   当然我们在底层有封装好的函数提供了,调用一下基于SOA服务理念的的功能函数

    // 用户是否有哪个相应的权限

    isAuthorized = ServiceManager.Instance.PermissionService.IsAuthorized(userInfo, permissionCode);

    就可以了,其中permissionCode 为例如 "Shopping.Admin.Access"、"DotNet.Admin.Access" 就可以了。

 

    用简单的思想解决复杂的的问题是关键、而不是用复杂的思想解决简单的问题。

    权限配置的参考页面为:

    权限分配的参考页面为:

    用户角色的关联,给角色配置权限的参考页面为:

 

    有灵活的配置功能,那就那些角色可以访问哪些系统,哪些用户又归属那些角色,哪些用户又可以访问哪些系统等等,都可以通过配置就可以达到目的了,不用修改程序源码,随时随着客户的需求变化,随时可以进行配置,很灵活,能经得起客户的折腾、需求的不断变化。

    有个设计得充分严谨、可以按自己的需求灵活配置管理,想怎么管理就怎么管理,想怎么设计就怎么设计的管理工具,还是没那么容易的,经得起考验的工具,才有重复利用的价值。

 

 

将权限管理、工作流管理做到我能力的极致,一个人只能做好那么很少的几件事情。