帮忙设计实体类

Question

数据库表是这样：
用户表：userinfo{userid varchar(50),username varchar(50),userpassword varchar(50)}
角色表：roleinfo{roleid int,rolename varchar(50),description varchar(100)}
用户角色关联表：userrole{userid,roleid}用户和角色是多对多的关系
请问这个关系的实体类应该怎么设计好呢
我看到有些orm设计中有什么 “单向”关联关系和“双向”关联关系，不知道是什么意思，
帮忙解释下好吗？

Answer 1

你在学习微软Membership数据库吗？

Answer 2

不是啊，我现在因为对orm不熟悉，所以实体类都是自己写的，但是对于数据库表有关系的（主要是多对多）
就不知道怎么设计实体类了，设计了之后对应的dal数据读取应该怎么读好（从性能上考虑）

Answer 3

到51aspx.com上看看，很多实例
双向关联：两个类都知道另一个类的公共属性和操作。单向关联：只有一个类知道另外一个类的公共属性和操作。大多数关联应该是单向的，单向关系更容易建立和维护，有助于寻找可服用的类
可看看Hibernate
http://blog.csdn.net/sokhoi/archive/2007/07/08/1682429.aspx

Answer 4

这个关系不难，给User实体类加个Roles属性，是List<Role>类型的。
orm不了解，偶也正想学。

Answer 5

3楼的兄弟，我上面的用户和角色是单向还是双向的？
4楼的兄弟和我想的差不多，但是我想做的在role类里面需不需要一个属性List<user>

Answer 6

List<roleInfo>
List<userInfo>
这两个都单独
role类里面不需要一个属性List <user>我今天刚做完一个后台管理权限系统。
参考：
http://www.noahweb.net/mail/2/Project.htm
http://blog.sina.com.cn/s/blog_5ec08bd50100csxw.html

Answer 7

用linq直接映射到数据库实体就可以了

Answer 8

这要看你所实际使用的orm的能力高低问题。如果是能力较高的orm，你可以这样设计协议public UserRole
{
   UserInfo User{get;set;}
   RoleInfo Role{get;set;}
}也就是说较高能力的ORM可以很好地支持OO设计。而较低能力的ORM可能根本不能支持。所以你要搞明白你所选择的所谓ORM是个什么货色，如果它在支持OO方面能力较低，就不得不重新拿出过去ADO.NET操作关系数据库那套做法来。

Answer 9

当然，如果这两类东西“紧耦合”，你也可以删除 UserRole 类，在User中定义   IEnumerator<Role> Roles{get;}
IEnumerator<Role>对于更高级和更低级的实现方法的兼容性更好。其实如果你了解了Linq，我就不赞成你再使用List<T>这个类型了。让我们把List<T>留给那些不懂Linq的架构师继续使用去吧。
还是那句话，你早晚还是要把代码落到实处。所以如果你定义了这个所谓“实体类”，结果你的ORM不能很好地、自动化地实现其接口协议，你定义这样高级的接口协议反而是自找麻烦。

Answer 10

那么userinfo和roleinfo关联的表的操作应该放在useinfodal做还是roleinfodal做

Answer 11

public UserRole 
{ 
  UserInfo User{get;set;} 
  RoleInfo Role{get;set;} 
}