在上一篇文章当中，我们建立了一个基于 NHibernate 和 Ninject 的 ASP.NET MVC 应用程序，设置了解决方案的结构和一些第三方程序集的引用。
在本篇中，我们将介绍持久化对象模型的建立。持久化对象模型是一组对象，用于我们保存数据到数据库。
注意：这是一个示例程序，和正确的应用程序结构有很大的差异。正如在 ALT.NET 空间里的大部分高级话题一样，Ayende 有一些关于持久化对象和领域对象的差别的信息。本系列的目的和它们是一样的。
首先，我们建立基于普通旧式CLR对象(POCO)的持久化模型结构。我喜欢在 Visual Studio 的类设计器中做这些事。因为它有助于我们专注在高层的实体和关系上面，而不用徘徊在具体的实现代码上。
以下是我们将要使用的模型图：
首先我们来看下 Course 和 Section 之间的关系。在 Course 类中有一个 ICollection 类型的属性，这个属性和 Section 类是一对多的关系。同样，在 Section 类中也存在一个 Course 属性，和Course 类是多对一的关系。
Code
好了，我们建立完了所需要的全部实体类。不过因为我们使用NHibernate，所以这里还有几个小要求：
- 所有的方法和属性都必须是可重写的，也就是在C#中必须声明为 virtual 。
- 除非你使用了依赖注入字节码提供者，否则你需要声明一个无参的构造函数。如果你不知道字节码提供者是什么，不用急，我们稍后会介绍的。如果你没有写任何构造函数，也没有错，因为默认会生成出一个无参的构造函数。不过因为 NHibernate 的要求，当你添加一个带有参数的构造函数的时候，也必须要加上一个没有参数的构造函数。
- 当某些需要用到只读属性的时候，你可以有一些选择。你可以告诉 NHibernate 你的命名约束为后备字段。不过我不喜欢这样，我喜欢将属性设置成可读写的，并且将 setter 设置为 rotected 。如果你刚开始使用 NHibernate 的话，你可能还没有见过这样的情况。
Code
我所有的集合属性都是这样设置的。你可以操作集合里的内容，但你不能替换另外一个没有继承此类的实例和重写属性。 如果你要是将这个属性设置成只读的，你就必须在 NHibernate 里配置 m_Sections 使用反射，这是一个完全没有必要的操作。我这样的做法更容易，而且得到的结果也都是相同的。
此外，请注意我们是从 Entity 类继承的，更多内容请继续关注。
接下来我们说说数据库。这些实体类最终都将变成数据库里的表，你会将表的主键设置成什么样的呢？ Fabio Maulo 有一篇非常好的随笔介绍了不同的 NHibernate 主键策略，他在 这篇随笔 中也提到了标示列可能不是主键的最佳选择。
那么，什么才是最好的选择呢？ 其实这是个见仁见智的问题。多亏 NHibernate ，我不想关注过多的数据库细节，所以我喜欢 guid 。你也可以选择你喜欢的，或者可以说是数据库管理员喜欢的。
现在，你打算如何确定对象的主键呢？ 在我看来，这的确是一个持久化细节 – 就是你的对象不应该真正的和它打交道。这就是为什么我们要把它隐藏在基类中，请记住我们要从 Entity 类继承。
public abstract class Entity
{
private Guid m_ID;
public virtual Guid ID {
get { return m_ID; }
protected set { m_ID = value; }
}
}
这篇讲的就是这么多了，在下篇教程里，我们将介绍如何配置 NHibernate 和建立数据库。
