NHibernate：如何用一对多的关系来表示多到多的关系？

Question

我在网上读过一篇文章(我再也找不到那篇文章了)，一段多到多的关系可以被一对多的关系所取代。有人能举个例子吗？

Answer 1

我只是想问这个问题，然后意识到，没有任何答案。这是一个遗憾，尽管我经常指出NHibernate文档声明：24.最佳做法

不要使用外来的关联映射。

真正的多到多关联的良好用法是罕见的。大多数情况下，您需要存储在“链接表”中的其他信息。在这种情况下，对中间链接类使用两个一对多的关联要好得多。事实上，我们认为大多数的关联是一对多的和多对一的，在使用任何其他的关联风格时，你应该小心，并问自己是否真的有必要。

下面的示例23.2.作者/作品..摘录，简化版本的多到多的关系Author和Work:

<class name="Work" table="works" ...>
        <id name="Id" column="id" generator="native" />
        ...        <set name="Authors" table="author_work" lazy="true">
            <key>
                <column name="work_id" not-null="true"/>
            </key>
            <many-to-many class="Author">
                <column name="author_id" not-null="true"/>
            </many-to-many>
        </set></class>

它的多对多目标作者：

<class name="Author" table="authors">
  ...  <set name="Works" table="author_work" inverse="true" lazy="true">
     <key column="author_id"/>
     <many-to-many class="Work" column="work_id"/>
  </set></class>

因此，如果我们想订购这套装货工程，我们确实有一个问题。对表中没有列。但更重要的是，没有办法管理这样的专栏。

我们所能做的就是引入对偶对象：AuthorWork并根据需要扩展对表。

public class AuthorWork{

    public virtual Author Author { get; set; }
    public virtual Work Work { get; set; }
    public virtual int OrderBy { get; set; }}

AuthorWork的映射

<class name="AuthorWork" table="author_work">
    ...    <many-to-one name="Author" column="author_id" />
    <many-to-one name="Workr"  column="work_id" />
    <property name="OrderBy" />

有了这个，我们可以将多到多的映射转换为一对多的映射，例如作者集合：

<set name="Authors" lazy="true"
  order-by="OrderBy">
  <key column="work_id" not-null="true"/>
  <one-to-many class="AuthorWork" /></set>

我们可以管理实体AuthorWork，设置OrderBy列，从而有效地处理配对表。

注：必须同意这一建议，在综述中提出的要求越多，我们就越高兴我们有办法来管理这种关系！

Answer 2

由于关系DBMS通常不支持多到多关系，所以这些关系使用一个链接表和两个一对多的关系来表示。例如，多到多之间的关系UserS和Roles表示为User one-to-many UserRoles many-to-one Role..NHibernate通常隐藏这一点，并允许多到多的关系商店透明。如果需要，可以始终选择显式地映射链接表。你会给我地图User, Role 和 UserRoles，在哪里UserRoles包含两个多对一的关系(到User和一个Role分别)在这种情况下User也不Role的收藏(一对多)UserRoles实例(或者至少它们可以是反向的)。这对于减少内存占用非常有用，因为您需要将较少的集合加载到内存中。缺点是查询变得更加复杂。