I'm currently developing an application server which employs a "classical" 3-layered design: Persistence Layer <-> Business Logic <-> Presentation

I use NHibernator for the PersistenceLayer and the mapping works pretty well. But by design, the PersistenceLayer encapsulates the used database access lib (namely NHibernate) and adds some extra functionality like caching and thread-safety via object locking.

If code wants to load db-objects it does not directly use NHibernate. It uses the LoadObject(..) call of the PersistenceLayer I coded. All db-objects must be loaded via this call, so my code can keep track of loaded objects for caching and thread safety.

That's where things get a bit complicated.. for example if an object contains a one-to-many relation, NHibernate loads the associated objects (on demand) implicitly without the knowledge of my caching/thread-safety code.

Is there a way to gain this level of control back from NHibernate to my code ? I want to use NHibernate as much as possible, but sometimes I need a higher level of control.

Is it even a good idea to try something like this with NHibernate ?

So far, sorry for the long post ;-)

thanks for your help and greetings !
Thomas

I think you need to look into the Interceptor interface..

The interceptor interface will give you some control within your entities but I'd avoid directly using this in your domain entities since you will effectively couple your persistence infrastructure (NHibernate) with your domain...not a good thing.
You may want to look into NHibernate's second-level caching mechanism and consider using that to manage all the details of caching for you. If that isn't suitable, you aren't required to have NHibernate load the collection upon Entity loading...I'd look at having a Repository in my domain layer deal with details about WHAT needs to happen and when and make calls only to abstractions of my Persistence Layer methods. Don't call your Persistence Layer implementation directly from your entities.