如何在NHibernate中处理大量的映射文件

Question

我们正在开发一个带有非常大型数据库的大型Windows窗体.NET应用程序。目前我们已达到400个表和业务对象，但这可能是整个应用程序的1/4。

我现在的问题是，如何使用NHibernate处理大量的映射文件，并考虑到性能和内存使用情况？ 业务对象及其映射文件已在不同的程序集中分隔。但我相信所有组件的NH SessionFactory将使用大量内存，性能将受到影响。但是，如果我只使用一部分程序集构建不同的工厂（可能类似于域上下文，它将逻辑部件中的程序集分开），我就不能轻易地在它们之间交换对象，只能访问对象的子集。

我们当前的方法是在上下文属性的帮助下分离业务对象。业务对象可以是多个上下文的一部分。创建SessionFactory时，给定上下文（一个或多个）的所有映射文件都合并到一个大的映射文件中，并在运行时编译为DLL。然后使用这个新的映射DLL创建Session本身。

但这种方法有一些严重的缺点：

• 开发人员必须处理业务对象程序集之间的程序集引用;
• 开发人员必须处理上下文，否则NHibernate将找不到类的映射;
• 新映射文件的创建速度很慢;
• 开发人员只能访问当前上下文中的业务对象 - 任何其他访问都会在运行时导致异常。

也许有一种完全不同的方法？关于这个问题，我会很高兴。

Answer 1

您需要知道的第一件事是 do not need to map everything 。我在工作中有类似的情况，我映射了我要使用的对象/表的主要子集，其他我通过ad-hoc映射使用它们，或者通过NHibernate（session.createSqlQuery）执行简单的SQL查询。我映射的那些，其中一些我使用Automapper，而对于那些比较粗糙的人，定期的Fluent映射（哎呀，我甚至有NHibernate调用跨越不同的数据库，如人力资源，财务等）。

就性能而言，我只使用一个会话工厂，我个人没有看到使用这种方法的任何缺点。当然，Application_Start比常规的ADO.NET应用程序需要更多，但在那之后，它将顺利通过。按需开始打开和关闭会话工厂会更慢，因为它们需要一段时间来梳洗。

Answer 2

由于SessionFactory应该是应用程序中的单例，因此内存成本在应用程序中不应该那么重要。

现在，如果SessionFactory 不是单身，那就是你的问题。