I have followed the practice of keeping my domain layer completely unaware of the persistence engine and the objects are therefore unable to see the NHibernate session.

The problem I have is that I want to be able to access some other objects in the domain that I am not able to navigate to via the object hierarchy.

What is the recommended approach for solving this problem?

Thanks,

Jason

It depends on the kind of application you are developing (ASP.NET or WinForms). ASP.NET approach is detailed in the docs (you can even use Hibernate docs, the web stuff is conceptually similar), WinForms are more complicated.

This is an interesting situation ... we haven't gotten to it yet ourselves, but as you describe it, I'm sure we will soon. We have already faced something similar though -- the need for code in the domain layer to create new entities, which may be subclassed (using the same class name but different namespace).

What we've done is to create an EntityServices singleton, which has an EntityFactory and EntityGateway that can be set during EntityServices' initialization (otherwise default implementations are used). The domain layer can know about EntityServices.Factory and EntityServices.Gateway, but does not know about NHibernate. The gateway may provide entities from a source other than NHibernate, and may understand queries of types other than HQL. No NHibernate types are exposed in the public API of EntityServices, EntityFactory or EntityGateway.

We will probably go a step further and define "named queries" of a sort. EntityServices (or EntityGateway) will have a registry of queries, where each query knows its "type" -- NHibernate or whatever else. Then any code executing queries simply requests them by name and parameters -- e.g.



and has no idea if NHibernate (or any persistence layer) is being used to provide the results. These queries could be executed from within the domain layer itself, without the problems of high coupling.

Hi Sergey,

I have spent quite a lot of time poking aroung in the docs and the forum but was unable to find an answer to this specific question. Can you please advise which doc contains information about this problem?

Thanks,

Jason

Hi Nels,

Thanks for the response.

I have only hit this need in one special case within the domain although I can imagine other places where it might also be required.

I have already created a service layer that the UI calls to interact with the domain and this provides methods for CRUD and searching of objects. The domain is obviously unaware of this service layer and would not be able to use it anyway as it requires a session to be passed in on the constructor and we don't have that in the domain.

However, I guess what you are proposing is another form of service layer that the domain can use. I am a bit unsure about how it knows how to create the session though as it needs to know what the database connection is and this comes from the UI configuration file. How do you handle this?

Cheers,

Jason

Our gateway that internally performs NHibernate operations gets the database connection info from hibernate.cfg.xml (or web.config if used with ASP.NET). NHibernate gets it for us, actually, when an instance of NHibernate.Cfg.Configuration is is created. We have a static method on our EntityServices singleton called Start() that the application needs to call to initialize stuff (it creates an NHibernate configuration object, adds domain assemblies to it, creates a SessionFactory, etc), but no parameters need to be passed to this Start() method.