c# - 关于多对多关系的OO问题(NHibernate的规划)

Question

我正在设计一个 OO 对象模型，并计划使用 NHibernate 作为数据访问层。

我想知道在处理彼此具有多对多关系的两个实体时的最佳 OO 设计(尤其是为了与 NHibernate 轻松集成)。

对象: 用户 - 单个用户可以与多个主题相关 主题 - 一个主题可以与多个用户相关

在 SQL 中，这种关系是直接使用多对多表；

tblUser
  userID

tblSubject
  subjectID

tblUserSubject
  userSubjectID
  userID
  subjectID

那么，应该如何创建纯 对象？每个对象都应该包含另一个对象的集合吗？示例:

class User 
{
   public int userID {get; set;}
   public List<Subject> subjects {get; set;}
}

class Subject
{
   public int subjectID {get; set;}
   public List<User> users {get; set;}
}

是否有更好的方法对此进行建模，以便 NHibernate 可以轻松地保持关系？

Answer 1

关于哪种设计最适合 NHibernate，我没有答案，但我想发表评论，因为这让我想起了 Rob Conery 在 Hanselminutes 上关于领域驱动设计的很多讨论。

我的本​​能 react 是，如果您的纯用户包含主题，同时您的主题包含用户，那是不对的。我想将它缩小到一个或另一个。有趣的是，Conery 正在讨论他的店面应用程序以及关于产品是否有类别或类别是否有产品的争论。事实证明，两者 都不是这种情况 - 它实际上是一种相切关系，最好由应用程序中的服务处理。 (至少，这是实现它的最佳 DDD 方式，因为这是他的客户关联实体的方式。)

因此，撇开 DDD，我想知道它是否可以帮助您认真审视用户和主题之间真正的纯粹关系是什么，以及其中是否包含另一个。由于我有点不喜欢它们中的每一个都包含另一个的想法，所以我可能会考虑更频繁地使用哪个子集合。在检索 User 时，您是否经常使用其 Subjects？相反，虽然一个 Subject 可能有与之相关的用户，但您在对 Subject 对象进行操作时是否经常使用此集合？如果不是，则该集合可能不直接属于它。

同样，我无法证明哪种设计最适合 NHibernate，但我认为这是值得考虑的事情。