NHibernate自定义集合类型（上）：基本实现方式

前天一篇文章中我说NHibernate的集合类型实现有些“尴尬”，它无法使用自定义集合类型，设计也有些古怪——不过在许多朋友的指点下，我意识到NHibernate是可以使用自定义集合类型的。至于它的设计是否合理（或者说是用是否方便？）……这就是这几篇文章中想要探讨的内容了。不少朋友给出了一些自定义集合类型的示例链接，我参考之余也自己找了一些资料，慢慢尝试，也终于有了一些体会。
这个小系列预计有上中下三篇，在这第一篇里主要是阐述在NHibernate中自定义集合类型的基本原理和方式，进而引发一些问题。第二篇主要便是解决问题，并为了简化开发提供一个思路和“通用”一些的实现。至于第三篇，便是一个“示例”，目的便是在领域模型中为一对多的双方维护双向的关系了。搞这些东西让我头大，因为资料实在太少，就算有也大多数是浅尝辄止，没有多少“通用”的东西，有些呢又过于复杂（在我看来也违背了一些“设计原则”），忽然找到一个似乎是有示例有详细说明的文章，却因为图片和代码全部丢失让我空欢喜一场。总而言之，我这几篇是在参考零散资料的基础上，“连猜带蒙”又经历了无数尝试和挫败总结出的结果——当然，您会发现，其实还很不彻底。
有时候我也想，难道各位用Hibernate和NHibernate的同志真没有遇到我需要的场景，真没有像我一样考虑这么多吗？还是我的想法过于古怪，实际上不会这么做？否则为什么互联网上的资料那么少……
言归正传，我们开始自定义一个集合。作为基本实现方式的演示，我还是打算使用上一篇文章中Question和Answer的一对多关系作为示例：

1. public class Question
2. {
3.     public virtual int QuestionID { get; set; }
5.     public virtual string Name { get; set; }
7.     private ISet m_answers;
8.     public virtual ISet Answers
9.     {
10.         get
11.         {
12.             if (this.m_answers == null)
13.                 this.m_answers = new HashedSet();
15.             return this.m_answers;
16.         }
17.         set
18.         {
19.             this.m_answers = value;
20.         }
21.     }
22. }
24. public class Answer
25. {
26.     public virtual int AnswerID { get; set; }
28.     public virtual string Name { get; set; }
30.     public virtual Question Question { get; set; }
31. }

复制代码

Question的Answers属性是ISet类型，但是这个集合类型太单薄了，我需要它包含一些辅助逻辑和功能都不行（扩展方法不是万能的），那么让我们来扩展它，让Question的Answers集合使用我们自定义的类型吧：

1. public class Question
2. {
3.     ...
5.     private IAnswerSet m_answers;
6.     public virtual IAnswerSet Answers
7.     {
8.         get
9.         {
10.             if (this.m_answers == null)
11.                 this.m_answers = new AnswerSet();
13.             return this.m_answers;
14.         }
15.         set
16.         {
17.             this.m_answers = value;
18.         }
19.     }
20. }
22. public interface IAnswerSet : ISet
23. {
24.     int Calculate();
25. }
27. public class AnswerSet : HashedSet, IAnswerSet
28. {
29.     public virtual int Calculate() { return 0; }
30. }

复制代码

我们基于ISet扩展了了一个IAnswerSet，并提供了一个Calculate方法（抱歉在这里我找不出合适的示例）。作为IAnswerSet的默认实现，我们也实现了AnswerSet类，它继承了HashedSet，因此也只需要实现额外的Calculate方法就可以了。这两个类非常简单。
不过，NHibernate又如何知道该怎么使用AnswerSet呢？那就需要我们提供一个IUserCollectionType来告诉它这些信息了：

1. public class AnswerSetType : IUserCollectionType
2. {
3.     #region IUserCollectionType Members
5.     public bool Contains(object collection, object entity)
6.     {
7.         return ((IAnswerSet)collection).Contains((Answer)entity);
8.     }
10.     public IEnumerable GetElements(object collection)
11.     {
12.         return (IEnumerable)collection;
13.     }
15.     public object IndexOf(object collection, object entity)
16.     {
17.         throw new NotImplementedException(); // 作为Set不需要这个方法
18.     }
20.     public object Instantiate(int anticipatedSize)
21.     {
22.         return new AnswerSet();
23.     }
25.     public IPersistentCollection Instantiate(ISessionImplementor session, ...)
26.     {
27.         return new PersistentAnswerSet(session);
28.     }
30.     public object ReplaceElements(object original, object target, ...)
31.     {
32.         var result = (AnswerSet)target;
34.         result.Clear();
35.         foreach (var item in (IEnumerable)original)
36.         {
37.             result.Add(item);
38.         }
40.         return result;
41.     }
43.     public IPersistentCollection Wrap(ISessionImplementor session, object collection)
44.     {
45.         return new PersistentAnswerSet(session, (IAnswerSet)collection);
46.     }
48.     #endregion
49. }

复制代码

我们要为AnswerSet实现一个AnswerSetType类型才能告诉NHibernate该如何使用IAnswerSet类型。AnswerSetType的大部分方法都是浅显易懂的，不作赘述。不过有一些东西可能不是那么明白：

• IPersistentCollection是什么？
  
• PersistentAnswerSet又是什么？
  
• 返回IPersistentCollection的Instantiate和Wrap方法又是什么？
  

这就涉及到NHibernate的一个重要功能了：自动跟踪集合状态。说是自动，其实当然还是要我们去告诉它“集合做出了哪些改变”的。怎么告诉呢？向ISessionImplemetor对象提供信息即可。那么怎么提供信息呢？通过IPersistentCollection。
这里又有一个“话题”，那就是为什么NHibernate一定要（还是“建议”？）我们为集合类型提供一个“接口”，而不是个具体类？这是因为它需要为这个接口使用不同的实现，来做到延迟加载，亦或是“跟踪集合状态”。例如下面的代码：

1. var session = ...;
3. var question = new Question { Name = "Question A" };
4. question.Answers.Add(new Answer { Name = "Answer A - 1", Question = question });
5. question.Answers.Add(new Answer { Name = "Answer A - 2", Question = question });
7. session.Save(question);
8. session.Flush();

复制代码

您认为，在question对象被保存进数据库之后，它的Answers集合是什么具体类型的呢？是AnswerSet吗？错了，它已经被替换成为PersistentAnswerSet类型（经过AnswerSetType.Wrap方法封装过）了。PersisitentAnswerSet的作用便是在提供了IAnswerSet的功能以外，还实现了IPersistentCollection接口，“同时”为NHibernate提供了“持久化信息”。很显然的是，PersistentAnswerSet和AnswerSet在IAnswerSet接口的功能上应该完全相同，否则前者就无法替代后者了。因此，PersistentAnswerSet理想的实现应该是这样的：

1. public class PersisitentAnswerSet : AnswerSet, IPersistentCollection
2. {
3.     ...
4. }

复制代码

那么我们又该如何实现IPersistentCollection接口呢？别急，先来看看它有哪些成员吧。嗯……什么，33个方法和12个属性？没错，IPersistentCollection便是这么一个庞然大物，因为它要为NHibernate提供太多信息了。比如，从上次保存之后弄脏了没有？添加过哪些元素，又删了哪些元素？太多太多了。而且，这些成员的作用是什么呢？也基本没有资料可以告诉我们必要的信息，似乎唯一的做法便是阅读代码了。因此，这简直叫人没法实现。
“幸运的是”，NHiberante内部提供了一个PersistentGenericSet类，实现了ISet所需的持久化操作。于是我们的PersistentAnswerSet可以基于它来实现：

1. public class PersistentAnswerSet : PersistentGenericSet, IAnswerSet
2. {
3.     public PersistentAnswerSet(ISessionImplementor session)
4.         : base(session)
5.     {
6.     }
8.     public PersistentAnswerSet(ISessionImplementor session, IAnswerSet collection) :
9.         base(session, collection)
10.     {
11.     }
13.     public virtual int Calculate() { return 0; }
14. }

复制代码

只可惜，为了保持和AnswerSet行为完全一致，我们必须在PersistentAnswerSet中也提供一个一模一样的Calculate方法了——如果AnswerSet还有其他实现，或者重写了ISet的Add，Remove等方法，我们在PersistentAnswerSet中也必须一一照办。这是一种臭不可闻的重复。
有人可能会说，那么我们不要AnswerSet类了，直接在PersistentAnswerSet提供IAnswerSet的行为，然后就在Question类中给出PersistentAnswerSet，不可以吗？从实现角度，可行。但是从设计角度上来说，不可取。因为Question是我们的领域模型，而PersistentAnswerSet依赖着NHibernate的持久化逻辑。如果在Question中直接使用PersistentAnswerSet，这就产生了领域模型到持久化逻辑的依赖了——这从领域模型设计起初就是一直在避免的。
从以上的示例中也可以看出，自定义集合的关键是在于提供一个IUserCollectionType以及一个IPersistentCollection对象。有了这两个保证，无论是Set，Bag，List还是其他任何的类型，从理论上来说，NHibernate都是支持的。但是事实上，几乎没有人去这么做。因为其中的设计有一些很古怪的，难以捉摸的地方。例如我除了基于Set的自定义集合之外，还尝试了基于Bag的开发，但是可谓困难重重。
Bag是基于Collection的，PersistentGenericBag构造函数接受的参数也是ICollection，但是在PersistentGenericBag内部却会将集合转化为ICollection——它和ICollection可没有任何联系（不像IEnumerable是基于IEnumerable的）。因此我强烈怀疑PersistentGenericBag只是在Java Hibernate的非泛型基础上，包装的一层机械封装而已。此外，在从集合内部删除元素并保存至数据库的时候，NHibernate还会尝试将我们的集合转化为IList类型。真是奇怪的做法。至于它对List的支持，对普通自定义集合的支持（这要求我们实现IPersistentCollection的45个成员）我就没有尝试了。说实话，我不信任NHibernate除Set以外的集合类型。以前在使用List的时候，也发现它的映射关系并不如文档上写的那么“符合List语义”。如果您感兴趣的话，我们也可以对这方面进行更多探讨和尝试。
还是回到AnswerSet吧，要使用IAnswerSet自定义集合类型，还需要进行配置。用Fluent NHibernate来写，它可能就是这样的：

1. public class QuestionMap : ClassMap<Question>
2. {
3.     public QuestionMap()
4.     {
5.         Id(q => q.QuestionID).GeneratedBy.Identity();
6.         Map(q => q.Name);
7.         HasMany(q => q.Answers)
8.             .LazyLoad()
9.             .CollectionType()
10.             .KeyColumns.Add("QuestionID")
11.             .Cascade.All()
12.             .Inverse();
13.     }
14. }

复制代码

目前我们的IAnswerSet支持向集合内添加元素，删除元素并保存，以及延迟加载，满足我基本操作的要求。不过以上还只是“基本实现方式”，在投入生产之前我们还是有两个问题必须解决：

• IAnswerSet不是个通用的实现方式，那么给出一个尽可能通用的扩展做法呢？
  
• 在AnswerSet和PersistentAnswerSet中实现两遍完全一样的逻辑是绝对不可取的，但是出现逆向的依赖也不好，那么我们又该怎么做呢？
  

这真的很不容易，下次我们再来设法解决这个问题。
相关文章

• NHibernate自定义集合类型（上）：基本实现方式
  
• NHibernate自定义集合类型（中）：通用实现方式
  
• NHibernate自定义集合类型（下）：自动维护双向关系
  

来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！