用NHibernate处理带属性的多对多关系

1、引言 老谭在面试开发人员的时候，为了考察他们的数据库开发能力，常常祭出我的法宝，就是大学数据库教程中讲到的一个模式：学生选课。这个模式是这样的： 在这个模式中，学生(Student)和课程(Course)都是实体，分别有主键Id。考试成绩(Score)是学生和课程

1、引言

老谭在面试开发人员的时候，为了考察他们的数据库开发能力，常常祭出我的法宝，就是大学数据库教程中讲到的一个模式：学生选课。这个模式是这样的：

在这个模式中，学生(Student)和课程(Course)都是实体，分别有主键Id。考试成绩(Score)是学生和课程之间的多对多关系。

基于这个模式，对于新手，可以出一些简单查询要求，对于熟手，可以出一些复杂的查询要求，用起来得心应手。

但今天要说的重点是，怎么用NHibernate实现这个模式。和一般多对多关系稍有不同的是，这个关系带有一个属性，就是考试成绩(Score)。

如果多对多关系上带有属性，我们一般会把这个关系扩充为实体，也就是把一个多对多关系转换为一个实体加上两个多对一关系。

如果多对多关系上有多个属性，将其转换为一个实体还是有必要的，但只有很少的属性（本例中只有一个），转换为实体实在有些浪费。因为一般情况下，对于实体，我们要为其创建一个人工主键，有了人工主键，又要创建一个序列。在映射时，这个实体自然要有对应的类。这一大堆事情，想想就非常麻烦。

问题的关键是，在概念上这本来就是一个关系，为了实现的方便，而将其转换为一个实体，这个凭空多出来的实体，使概念变得复杂，非常别扭。

因此，这里要探究一下，让关系恢复为为关系，怎么用NHibernate来处理。

2、映射

如果关系表Score中没有Score那个属性字段，Student实体可以映射为这样的类：

public class Student
{
    public virtual long Id { get; set; }

    public virtual string Name { get; set; }

    public virtual IList Courses { get; set; }
}

Course也类似。

但有了属性Score，再这样映射就把这个属性丢了。为了带上Score属性，两个实体应该这样映射：

public class Student
{
    public virtual long Id { get; set; }

    public virtual string Name { get; set; }

    public virtual IDictionary Courses { get; set; }
}

public class Course
{
    public virtual long Id { get; set; }

    public virtual string Name { get; set; }

    public virtual IDictionary Students { get; set; }
}

原来的列表（List）变成了字典（Dictionary），字典的主键是原来列表中的元素，值则是关系上的属性值，即考试成绩。

对应的映射文件自然也要调整，结果如下：

...


  
    
    ...
  

  
    
  

  
...

     
  
       
      ...
  

  
    
  

  

经过这样的映射，多对多关系中的属性带到了类中，而且避免了为关系创建实体——没有Score这样的类。对这样映射结果的操作，和常规多对多关系映射方式多生成的基本类似，但也有几个要注意的问题。

3、查询

对于一些简单的查询，如：

都比较容易处理，因为这只需要在一个实体上加过滤条件。

如果需要在两个实体上加过滤条件，如查询小明化学课的成绩，就有些复杂，其查询语句Hql是这样的：

select score
  from Course c, Student s
  join c.Students score
 where c.Name='化学'
   and index(score) = s.Id
   and s.Name='小明'

这里出现了我们很少用到的hql函数：index()。这是专门应对map的，其目的是获得map的索引字段。

吊诡的是，虽然我们指明，map的key是对象，如Course.Students的key是Student的对象，但index()的结果，仍然是 中 column字段的值。在上面的查询中，index(score)，我们期望的结果是Student对象，但结果却是对象的Id。因此，在查询语句中，我们不得不关联上Student s，并利用 s.Name 进行过滤。

即便是“简单的查询”，如查询小明所有课程的成绩，也有一个问题要注意。这个问题和懒加载相关。

在这个查询中，我们已经知道需要获取所有课程，因此，希望进行预先加载：

 from Student s
 join fetch s.Courses course
where s.Name='小明'

得到结果后，如果脱离查询的环境，如释放Session，在访问课程时，如：

s.Courses.Select(c => c.Key.Name)

4、维护

除了查询，在对关系进行维护时，也有一点值得特别注意：save-update类型的cascade无效。

cascade属性，为我们进行关系维护带来不少便利。在常规（不带属性）的多对多关系中，我们的维护操作可以是这样的：

小明选化学课：

using (var tx = session.BeginTransaction())
{
    var student = GetStudent(studentName) ??
                  new Student { Name = studentName, Courses = new List() };

    var course = GetCourse(courseName) ??
                  new Course { Name = courseName, Students = new List() };

    if (!course.Students.Contains(student))
    {
        course.Students.Add(student);
    }

    session.SaveOrUpdate(course);

    tx.Commit();
}

其中，GetStudent(studentName) 和 GetCourse(courseName) 分别是指，根据学生名字或课程名字从数据库中加载相应对象。在上面的代码片段中，如果数据库中没有，则新建。维护关系后，进行保存。

需要注意的是，在保存 course 的时候，并没有确保 student 是一个持久化的对象。如果student尚未被持久化，则在保存时，NHibernate会自动保存，并维护和course的关系。能够这么做，依赖于Course中关系上的cascade属性定义（第三行末尾）：

  
    ...
    
      
      
    
  

但在包含属性的多对多关系上，由于要使用map，就无法进行这样的配置——配置了也不生效。如果数据库中尚未保存该学生，我们不得不首先创建并将其持久化（第7行）：

using (var tx = session.BeginTransaction())
{
    var student = GetStudent(studentName);
    if (student == null)
    {
        student = new Student {Name = studentName, Courses = new Dictionary()};
        session.Save(student);
    }

    var course = GetCourse(courseName) ??
                 new Course {Name = courseName, Students = new Dictionary()};

    if (course.Students.ContainsKey(student))
    {
        course.Students[student] = score;
    }
    else
    {
        course.Students.Add(student, score);
    }

    session.SaveOrUpdate(course);

    tx.Commit();
}

否则，就等着NHibernate抛出异常吧。

5、结论

用Map/Dicitionary表达的多对多关系，要比用Bag/List所表达的，操作起来更为复杂。但这样的代价，我们乐意承担。

这是因为，我们更看重模型设计，更重视概念完整性。是模型决定具体实现，而不是反过来，根据具体实现来修改模型的设计。