Question

I’m writing an ASP.NET MVC application using NHibernate as my ORM. I’m struggling a bit with the design though, and would like some input.

So, my question is where do I put my business/validation logic (e.g., email address requires @, password >= 8 characters, etc…)?

So, which makes the most sense:

1. Put it on the domain objects themselves, probably in the property setters?
2. Introduce a service layer above my domain layer and have validators for each domain object in there?
3. Maintain two sets of domain objects. One dumb set for NHibernate, and another smart set for the business logic (and some sort of adapting layer in between them).

I guess my main concern with putting all the validation on the domain objects used by NHibernate. It seems inefficient to have unnecessary validation checks every time I pull objects out of the database. To be clear, I think this is a real concern since this application will be very demanding (think millions of rows in some tables).

Update:
I removed a line with incorrect information regarding NHibernate.

Answer 1

To clear up a couple of misconceptions:

a) NHib does not require you to map onto properties. Using access strategies you can easily map onto fields. You can also define your own custom strategy if you prefer to use something other than properties or fields.

b) If you do map onto properties, getters and setters do not need to be public. They can be protected or even private.

Having said that, I totally agree that domain object validation makes no sense when you are retrieving an entity from the database. As a result of this, I would go with services that validate data when the user attempts to update an entity.