How to handle a large ammount of mapping files in nHibernate

Question

Hello,

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 thats maybe 1/4 of the whole application.

My question now is, how to handle this large ammount 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 aproach is to separate the business objects with help of an 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 an 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 busines 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.

Regards

MoJo

Answer 1

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.

Answer 2

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.