In terms of using nHibernate in a real world application, can somebody provide an opinion on the following:

1. Creating a singleton for the session factory and getting an instance to open sessions. Are there any problems with this approach?

2. Creating a base class which knows how to save, load, delete to abstract nHibernate from business objects in order to facilitate a swap of ORM down the track.

1- No problem.

2- That's a possible solution... You may also implement a Gateway.

Hi KPixel,

Thanks for the response.

Can you elaborate on what you mean by Gateway? Or point me to the correct resources?

Thanks

Fowler defines "Gateway" as "an object that encapsulates access to an external system or resource". You might look at implementing a "Table Data Gateway" to encapsulate your NH calls. This kind of structure is very tightly bound to your relational model however, which tends to work less effectively as the complexity of your domain model increases. My preference is use the "Repository" design pattern, which is more aligned with the domain model.

So you would have a Repository class for each persistent class in your domain layer (e.g. CustomerRepository, OrderRepository, etc...). Then you would place methods on each repository class that perform the relevant persistence operations for the associated domain class. So for example, you might have CustomerRepository.SaveCustomer(...) or CustomerRepository.FindByName(...).