NHibernate Architecture and Business Logic

Just started developing a project using NHibernate and Fluent NHibernate for the mapping and I'm confused. Since the project is going to get more complex over the next months I would like to structure the code into logical layers such as Persistence Layer and Business Logic layer.

I have a business object called Patient that contains logic and validation.

Should Patient class be mapped with the Fluent NHibernate mapping class?
Or should the mapping class map to some Data Access Object, such as PatientDAO and Patient class somehow use PatientDAO?

If 1, isn't my Business logic layer and persistence layer the same? If 2, having the two layer is separate projects, should I the BL project contain the Patient object and some IPatientDAO and the PL have the PatientDAO object?

Or am I doing it all wrong? :-)

You should map your entities using Fluent NHibernate, since that is where you map to/from your database structure to your object model.

As for DAO, this is a matter of personal taste. Generally folks like to use a DAO of some sort (even though folks like to call them Repositories these days). These classes will utilize the NHibernate ISession to read/write the data to and from the database. Generally the current means of working with these is to define a generic interface with Get<T>(int id), GetAll<T>(), 'Delete()type methods defined to handle CRUD ops, withT` being the entity type.

It is, however, also possible to use the ISession directly in your presentation code, since it is already providing an abstraction for reading/writing data. If you go this route then you are exposing NHibernate to the rest of your app, but your also removing one level of abstraction.

As for which layer is which, NHibernate is 95%-100% of your persistence layer. You can add some abstractions of your own on top of it to create an API that makes you happy, but that is totally up to you.

Thanks for your answer.So entities contain business logic and validation? If so, then I guess I am using the Active Record (An object that wraps a row in a database table or view, encapsulates the database access, and adds domain logic on that data) pattern Fowler talked about in PEAA.What about if the domain logic is complicated and after reading Folwer's book I'm more interested in using Domain Model (An object model of the domain that incorporates both behaviour and data) along with Data Mapper.How can you use NHibernate with Domain Model (using inheritance, polymorphism etc.)?

moonz 2010-06-16 23:56:44

Another much shorter, the NHibernate files that are in the persistence layer, are those the class map files and some configuration files?I read that the class map files should be as close as possible to the files they map to, in my case in the business layer.

moonz 2010-06-17 00:05:30

I may have to do this in multiple comments, but we'll see...NHibernate supports using a full-fledged Domain Model pretty readily. As a matter of fact, since you can do things like set up entity references without needing a bunch of additional properties to track the IDs of the entities your referencing, it is one of the cleaner solutions. It also supports inheritance in your entity classes and allows you to specify which of the polymorphic table mapping styles you want to use (as mentioned by Fowler). Put whatever logic in the entity that makes sense for that entity.

ckramer 2010-06-17 00:18:38

For your second questions, the mapping file don't have to be in the same location as your entities, but it makes maintenance much easier. If you opt for something like FluentNHibernate, which is a replacement for the XML mapping files, you can put that configuration wherever you like. I typically put in in with my "Infrastructure" code, all the bits that are setting up the NHibernate session factory, IoC containers, that sort of thing.

ckramer 2010-06-17 00:21:13

ansaurus

tags:

views:

answers:

NHibernate Architecture and Business Logic

related questions