NHibernate支持空类型

    NHibernate 1.2 为表所带来的新性能支持nullable类型。以前，Nullables.NHibernate 的引用支持nullable类型，但是，不在需要这一类型。在HBMs里，没必要对待Nullables。

    属性映射不同于其它属性映射；简单地映射nullable的属性，就像对待其它任何属性一样。NHibernate 足够聪明，能在数据库和nullable的属性（它映射的）之间传输null 。 看一看BasicSample.Core/Domain/Order.cs ，它一个使用了nullable DateTime.的示例。

    尽管能很简单地操作对nullables的属性支持，只有通过仔细的考虑，才能使用。我自己的经验导致我不能在数据库（允许零）内创建列。依我看来，在数据库或者领域层内，映射零到原始的类型没有什么意义。nullables的DateTime属性是我能想起的唯一异常现象。很明显，这里有大量的有效形式，来和非原始关系一起使用null，但是，即使在那个时候，使用Null Object pattern是检查null（被代码分散的）的一个好选择。

NHibernate支持存储过程

    NHibernate 1.2支持存储程序，是这个构架性能的关键补充。但是，如果NHibernate处理了所有的CRUD，与存储proc连接到底有什么好处？有两个原因：和遗留数据库一起运转，以及执行报告查询。创建一个存储程序，返回集中查询的报告报告数据是轮流检测数据库的另一个选择。为了解释，Northwind数据库维护由每一个顾客发出的订单。

    假设你需要返回每一个产品的数量，数量是由特定的客户要求的。类型BasicSample.Core/Domain/HistoricalOrderSummary.cs 是一个值对象，此值对象压缩这个总结信息。注意这个类型没有从DomainObject继承，也没有响应的HBM文件。从NHibernate的角度来看，这是一个"非托管"类型，不能与非托管 C#相混淆。文件HistoricalOrderSummary.hbm.xml 定义一个指定的查询，这个指定的查询建立了一个到存储程序CustOrderHist的呼叫，为了返回需要的报告数据。（当解剖 BasicSample.Data项目时，将在下面讨论这个数据是怎样被转换成领域对象的）

    提供性能，与存储程序相交流导致了这一问题：存储程序应该执行什么，领域层应该执行什么。作为存储proc 的另一个选择，要满足前面提出的要求，C# 代码要能恢复特定客户发出的所有命令，把它们以环连接起来，总结每一个产品的数量。但是很明显，拥有SQL Server 来执行这一总结，将会有效得多；想象如果客户已经发送了成千上万个命令，将会是怎样？。If,如果，另一方面， 在允许领域层做这份工作和让存储程序做这份工作之间，性能分析在效率方面没有什么差别，然后让领域层做这份工作。你将发现这将带给它一个更完整的领域驱动设计以及更好的结果代码的可再用性。正如经常在发展阶段碰到的，在更好的领域驱动设计和优化了的性能之间有一个综合利用…… 直到瓶颈发现后，总是偏向领域。正如在介绍中提到的，阅读Peter Weissbrod's article中的介绍，此介绍证明与NHibernate相关的瓶颈。意外的是，与我相牵连的第一个NHibernate是50,000 LOC,总共要求6个存储程序，来帮助优化数据查询性能。这应该告诉你：在没有一个客观的性能提高时，你可以放在领域层放多少。