NHibernate architecture?

Question

I'm planning to implement my next project (asp.net MVC) by using nhibernate as an ORM. Since I do not have experience with nhibernate, I wondering how I should organize dependencies between different projects. I've seen something like this as a recommended approach:

• UI depends on Model, Repositories and NHibernate
• Repositories depend on Model and Nhibernate

    ----- UI-----------------------------
   |                |                    |
   |                |                    |
    Model  NHibernate

The problem is I do not want UI code to interact directly with nhibernate, so I'm thinking of something like this:

• UI depends on Model and Facade
• Facade depends on Model and Nhibernate

----- UI-------- | | | | Model

Facade, will actually have the repositories as well as encapsulating the nhibernate objects.

Does this sound reasonable? Is there any guideline on the preferred architecture?

Thanx

Answer 1

Catharsis might have what you are looking for.

Answer 2

Yep. That sounds about right. I never used NHibernate but having your model shared between your UI and a facade sounds good. Of course there is many different way to reach the same goals but yours looks good. :)

Answer 3

You've stated that you plan to use the MVC pattern. This implies that your UI will not be interacting with the data tier (in your case, NHibernate). What will be interacting with the data tier is your business tier, and your UI will interact with your business tier.

I'm not familiar with ASP.NET, so I can't advise you on a pre-built structure for this, but in Java, which is what I primarily use, you would have your EJBs isolate your UI from the data tier by making all such calls through the EJBs.

Think about isolating the code for each tier. You have a box for each tier, and each box can only communicate with a box below it through specific channels. So your data tier communicates with your database, your business tier communicates with your data tier, and your UI communicates with your business tier. All of these communications are one-way (that is, your data tier does not know about the business tier, etc). This means that if you wanted to replace any tier with a new implementation, the impact to the rest of your program can be kept to a minimum.

The actual implementation you use for NHibernate is not really relevant to the use of MVC, except for the fact that your UI will not be aware of how the data is stored or accessed.

Answer 4

This is generally what I do in my apps:

• Foo.Core

  • contains domain objects, business logic, etc
  • no reference to any infrastructure related assemblies, such as web services, ESBs, or data access
  • some people also put repository interfaces here, but that's a design choice. It allows you to have your domain services here, which interact with repositories, still decoupled from NHibernate

• Foo.Persistence

  • references to NHibernate
  • Repository implementations
  • Unit of work HttpModule for ASP.NET (helps control NHibernate's session lifecycle in a web app)

• Foo.Web

  • reference to both Foo.Core and Foo.Persistence
  • HttpModule reference to control the NHibernate Session

Foo.Web never interacts with NHibernate directly... it's always through the repositories. With an IoC container you can just request IRepository and not care what the implementation is.