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

我们正在研究一个大型数据库的Windows窗体.NET应用程序。目前我们达到了400个表格和业务对象，但这可能是整个应用程序的四分之一。如何在NHibernate中处理大量的映射文件

我现在的问题是，如何处理这个大量的与NHibernate的性能和内存使用情况的映射文件？业务对象及其映射文件已在不同的程序集中分离。但我相信所有装配的NH SessionFactory将使用大量内存，性能将受到影响。但是，如果我只用程序集的一个子集构建不同的工厂（也许像是一个领域上下文，它将逻辑部分中的程序集分开），我无法轻松地在它们之间交换对象，只能访问一部分对象。

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

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

开发商必须考虑业务对象组件之间的装配引用的照顾;
开发人员必须处理上下文，否则NHibernate将无法找到类的映射;
创建新的映射文件很慢;
开发人员只能访问当前上下文中的业务对象 - 任何其他访问都会在运行时导致异常。

也许有一个完全不同的方法？尽管如此，我会很高兴。

来源

2010-09-11 MoJo2600

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

就性能而言，我只使用一个会话工厂，而且我个人还没有看到使用这种方法的任何缺点。当然，Application_Start比普通的ADO.NET应用程序要多，但在此之后，它可以顺利通过。按需开始和关闭会话工厂的速度会更慢，因为它们需要一段时间才能清理干净。

来源

2010-09-11 15:57:56 rebelliard

感谢您的回答。好的，我已经看过Fluent nHibernate，但临时映射对我来说是新的。让我们来看看 – MoJo2600 2010-09-12 16:44:28

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

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

来源

2010-09-12 17:48:19

好的......这就是我以前在过去的项目中使用SessionFactory的方式。但是这个上下文系统是在我进入该项目之前创建的。你有更多的信息为什么SessionFactory应该是单身人士吗？ – MoJo2600 2010-09-13 09:11:08

因为创建，不可变和线程安全的代价很高。 – 2010-09-13 11:55:43

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

回答

相关问题