我觉得这个问题可以简单处理一下:
首先有一个权限的枚举
enum UserRight
{
DoSomething1 = 0x01,
DoSomething1 = 0x02,
......
}
角色枚举
enum Role
{
Player = 0x01,
Coach= 0x02,
......
}
人员类型
Person
{
string name {get;set;}
List<Role> roles = new List<Role>();
List<Role> GetRole()
{
return roles;
}
void AddRole(Role r)
{
roles.Add(r);
}
void RemoveRole(Role r)
{
roles.Remove(r);
}
}
再有一个授权权的静态类
Static Authorization
{
bool CanDo (Person p, UserRight ur)
{
// 根据p的角色具体判断,可能根据配置判断
}
}
使用
main()
{
Person p =new Person();
p.name = "刘国梁";
p.AddRole(Role.Player);
//如果想做一些队员的事情
if (Authorization.CanDo(p, UserRight.DoSomething1) == true)
{
}
}
代码是我自己在记事本里面打的,就是这个意思吧!请参考
你这个涉及到2格东西 人员,身份和操作
首先建立3格实体类
一个人员表(user) id name
一个身份表(userright) id right(这里填教练,队员什么的)
一个操作表(action) id actiondescribe
如果都是多对多关系的话 在加个用户关联身份表 和一个身份关联操作表就可以了
用户关联身份表 (userAssocUserright) userid userrightid
身份关联操作表 (userrightAssocAction) userrightid actionid
至于是不是多对多自己分析(反正多对多是可以兼容各种情况的)
至于身份变化那是程序控制的 起发起条件类似与事件
只有满足一定的条件才回变化
至于程序控制角色变化 主要看你的规则是什么
如果仅仅是想改变的时候改变 只要更新用户 和 身份的关联表就可以了
如果是按时间来的话 那么在用户表里就应该添加时间字段
程序每回调用用户的时候判断 时间是否达到转教练的程度(不过我觉得没意义,在实际情况中那个会因为资历而让某人升职,一般都是上级选的)
至于你说怎么构建什么的=。=
就是一个动作的大接口 底下继承 ICoach IPlayer 等小接口(其实这层应该是类的 为什么你要用接口也搞不明白)
在获取动作的大接口类型的时候 在那个位置判断身份就可以了
用身份对应接口就可以了
反正你说接口什么的 我看起来有点混乱
我觉得这个顶多就是数据库上的设计 和程序的设计没什么关系
模型1
体育从业者
队员 教练
体育从业者 是抽象类,下面两个从体育从业者继承
体育从业者 刘国梁 = 根据条件实例化为不同的角色。
这种模型的缺点是 同一个人不能同时具备不同角色的功能。
模型2
刘国梁同时实现 IPlayer, ICoach, IRole 三个接口
[Flags]
enum Role
{
Player = 0x01,
Coach= 0x02,
}
Interface IRole
{
Role Role {get; set;}
bool CanDo (Role role);
}
IPlayer, ICoach 中每个方法和属性实现时第一句都要调用一下
CanDo 判断一下是否具有这个权限,没有权限抛出异常
如
IPlayer 中
if (!CanDo(Role.Player))
{
throw new Exception("xxx");
}
这个模型的缺点就是比较复杂,每个方法都要加权限判断,同时这个实现的类也比较臃肿,即使刘国梁不是队员了,还是要实现队员的功能。
刘国梁的身份并不是只是由于时间而变化,还因为他自身的阅历增长,甚至政治环境等等而变化。
个人觉得这种情况在计算机里面表现,就是一个用户由A角色修改为B角色。角色转换之后根据角色的定义就可以做不同的操作,仅此而已
根本不应该让刘国梁去实现IPlayer或ICoach接口,而是应该给刘国梁一个IPerson接口,我相信怎么变他都是一个人
随后给一个IPersonBehavior接口,IPlayer和ICoach都是这个接口的子接口,让刘国梁拥有特定的Behavior就行
当然如果Player和Coach之间根本不能抽象,这里也就不能设计了
我还是感觉应该使用角色授权来解决,Player和Coach只是二个不同的角色而已,所以当身份发生变化时,只需要简单修改用户所属的角色即可解决
为什么要理解成这是随时间变化的呢?
如果这都能理解成随时间变化那任何变化都是随时间变化。随时间变化那只能是那些仅由时间引起的事件(如天亮天黑、过年过节)。就算当成随时间变化也不应该理解成是这个人变化了,变的只是他身上的角色。设计上的困难是因为理解的错误造成的。
我觉得设计可以很简单:
1、给person一个角色属性;
2、可以添加或删除角色;
3、每种角色都有自己支持的行为。
4、人工作上的行为都不是个人的行为,而是他所扮演的那个角色的行为
所以可以这样(刘国梁.PersonRole["教练"].发彪())这是刘国梁以他教练的身份发彪~~~
刘国梁.PersonRole["教练"].发彪()这里的索引方法 如果可以实现自己的索引方法会更好, 如实现以下的访问方法:刘国梁.PersonRole[Role.Coach].发彪()