I'm doing some analysis in regards to moving our existing application so that it will use NHibernate instead of our custom-developed layer for persistance.

We have both web and window sections to the app. For the web, keeping the SessionFactory in the HttpApplication Context should be good enough to give us decent performance.

But in the winform section, I'm curious to see what other people are doing.

The time taken to create a SessionFactory, with only a small subset of our domain objects mapped, is far from insignifficant. Although it only needs to be done once per startup of the application, ideally we'd like to be able to configure the sesion factory once per install

From what I understand, there is currently no way to serialize the session factory - so this may not be possible - so what is everyone else doing?

I'm creating the IsessionFactory just once, at startup, and I keep it in a singleton 'AppSettings' class.

we also hold the session factory in a singleton which is instantiated at startup.

Additional we have set the property "hibernate.use_reflection_optimizer" to false, which improves the startup performance dramatically if you have to map many classes. The disadvantage of this is, that NHibernate always uses reflection when accessing the properties of your mapped classes but for us the performance loss is acceptable.

Regards
Klaus

Thanks, that's sort of what I was planning on doing.

I'm investigating perhaps keeping a stub of the application, with only the ISessionFactory kept alive in memory and restarting the app when neccessary.

I also wonder: how do you do session / transaction handling in WinForms ?

Do you leave your session open for the complete use-case, and do you discounnect your connection each time you do not need DB access ?

For instance, say you have a form where you can edit an existing product.

When the form is loaded / executed, you can retrieve the product from the DB, once that's done, you can disconnect the underlying connection of the ISession, but keep the session itself open.

Then, each time you need DB access while the form is open, you can reconnect your session, and when you close the form, you can persist the changes you've made and close the ISession.

What do you guys think ? Is this a good approach ? Are there any other, better approaches ?

We buildour application like an n-tier application (although it's a classic client / server) with a separate businesslogic and data access layer. The implementation is a bit like a web application and is based on the MVC-pattern.

Our forms only contains code to bind / unbind the data to the controls and some basic validations. Session handling is done in the data access layer and transaction handling is done in the business logic layer. All NHibernate logic is encapsuled in the data access layer. The other tiers just work with the persistent objects.

The general way to read or save data in our application is:

Open session, Read / write the data, close session.

If we need transactions we open a session and start a transaction on it. The session becomes a unique id and is cached in a Hashtable. The id is returned to the business logic which uses the id for all CRUD operations that belongs to the transaction.

Regards
Klaus

[quote="luedi"]

Our forms only contains code to bind / unbind the data to the controls and some basic validations. Session handling is done in the data access layer and transaction handling is done in the business logic layer. All NHibernate logic is encapsuled in the data access layer. The other tiers just work with the persistent objects.[/]
Hmm, I do not like this approach.
The business logic layer is not aware of the context; I mean, in the business logic, you cannot know what the transaction boundaries are. Only the 'client' knows it. (Unless offcourse your business logic layer is actually a 'service layer' that implements all the use cases).

i don't want to start a discussion about application architecture but i cannot fully agree with you. The business logic handles business transactions which are normally achieved in a specific context. The data needed for a business transaction is normally handled as an entity which is read and written from / to the database in a transaction. I agree with you that the implementation details of handling a transaction should be placed in a service layer, but the business logic needs to know the boundaries of a transaction otherwise it could not handle the business transaction. The client do not need to know anything about the business transactions and transaction boundaries, he just has to display the data.

Regards
Klaus