NHibernate中如何处理大量映射文件
我们正在开发一个带有非常大数据库的大型 Windows 窗体 .NET 应用程序。目前我们已达到 400 个表和业务对象，但这可能是整个应用程序的 1/4。
我现在的问题是，如何使用 NHibernate 处理如此大量的映射文件，同时考虑到性能和内存使用情况？ 业务对象及其映射文件已经分离在不同的程序集中。但我相信包含所有程序集的 NH SessionFactory 将使用大量内存，并且性能会受到影响。但是，如果我仅使用程序集的子集（可能类似于域上下文，它将程序集分隔为逻辑部分）来构建不同的工厂，我将无法轻松地在它们之间交换对象，并且只能访问对象的子集。
我们当前的方法是借助上下文属性来分离业务对象。业务对象可以是多个上下文的一部分。创建 SessionFactory 时，给定上下文（一个或多个）的所有映射文件都会合并到一个大映射文件中，并在运行时编译为 DLL。然后使用这个新的映射 DLL 创建Session本身。
但这种方法有一些严重的缺点：
- 开发人员必须处理业务对象程序集之间的程序集引用；
- 开发人员必须处理上下文，否则 NHibernate 将找不到类的映射；
- 新映射文件的创建速度很慢；
- 开发人员只能访问当前上下文中的业务对象 - 任何其他访问都将导致运行时异常。
也许有一种完全不同的方法？我会很高兴对此有任何新的进展。
We're working on a large windows forms .NET application with a very large database. Currently we're reaching 400 tables and business objects but that's maybe 1/4 of the whole application.
My question now is, how to handle this large amount of mapping files with NHibernate with performance and memory usage in mind?
The business objects and their mapping files are already separated in different assemblies. But I believe that a NH SessionFactory with all assemblies will use a lot memory and the performance will suffer. But if I build different Factories with only a subset of assemblies (maybe something like a domain context, which separates the assemblies in logic parts) I can't exchange objects between them easily, and only have access to a subset of objects.
Our current approach is to separate the business objects with the help of a context attribute. A business object can be part of multiple contexts. When a SessionFactory is created all mapping files of a given context (one or more) are merged into one large mapping file and compiled to a DLL at runtime. The Session itself is then created with this new mapping DLL.
But this approach has some serious drawbacks:
- The developer has to take care of the assembly references between the business object assemblies ;
- The developer has to take care of the contexts or NHibernate will not find the mapping for a class ;
- The creation of the new mapping file is slow ;
- The developer can only access business objects within the current context - any other access will result in an exception at runtime.
Maybe there is a complete different approach? I'll be glad about any new though about this.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您需要知道的第一件事是您不需要映射所有内容。我在工作中遇到过类似的情况，我映射了要处理的对象/表的主要子集，而其他对象/表我要么通过临时映射使用它们，要么通过 NHibernate (session.createSqlQuery) 执行简单的 SQL 查询。我映射的，其中一些我使用了 Automapper，而对于更烦人的，则使用常规 Fluent 映射（哎呀，我什至有跨越不同数据库的 NHibernate 调用，例如人力资源、财务等）。
就性能而言，我只使用一个会话工厂，而且我个人没有发现使用这种方法有任何缺点。当然，Application_Start 比常规的 ADO.NET 应用程序需要更多的时间，但在那之后，一切都会顺利进行。按需启动和关闭会话工厂会更慢，因为它们确实需要一段时间才能更新。
The first thing you need to know is that you do not need to map everything. I have a similar case at work where I mapped the main subset of objects/tables I was to work against, and the others I either used them via ad-hoc mapping, or by doing simple SQL queries through NHibernate (session.createSqlQuery). The ones I mapped, a few of them I used Automapper, and for the peskier ones, regular Fluent mapping (heck, I even have NHibernate calls which span across different databases, like human resources, finances, etc.).
As far as performance, I use only one session factory, and I personally haven't seen any drawbacks using this approach. Sure, Application_Start takes more than your regular ADO.NET application, but after that's, it's smooth sailing through and through. It would be even slower to start open and closing session factory on demand, since they do take a while to freshen up.
由于 SessionFactory 应该是应用程序中的单例，因此内存成本在应用程序中不应该那么重要。
现在，如果 SessionFactory 不是单例，那么问题就来了。
Since SessionFactory should be a singleton in your application, the memory cost shouldn't be that important in the application.
Now, if SessionFactory is not a singleton, there's your problem.