hope this answers your question:
http://davybrion.com/blog/2009/10/why-nhibernate-entities-need-a-public-or-protected-parameterless-constructor/

NHibernate allows a private default constructor for Value Objects, but for Entities you will need a default public or protected constructor as private is not sufficient.

I too am trying to determine how well NHibernate lives up to the promise of persistence ignorance. I can definitely live with unnecessary private constructors, but I’m dubious about adding protected constructors just to support an ORM.

At any rate, I was surprised by the sentence I quoted, because I didn’t realize there were any circumstances in which NHibernate required protected default constructors.

BTW I am a major supporter of NHibernate. IMO its definitely the best ORM available for the technologies I use. I also aspire to write software using DDD methods so Im just trying my best to marry the two (NHibernate + DDD that is!)

Cheers

“In my opinion, you cannot just assume that the database is correct. In 99% of applications concerning a database – some manual maintenance interaction with the database is required and just because the code guarentees value object validity when saved, you cannot assume the value object is correct.”

i really think that depends on application to application. In some cases, you will be able to depend on it, in some you won’t. 99% is definitely pushing it a little bit too far, i think

in those cases where you do control the database completely, i think a private default constructor with a custom constructor which does validity checks is sufficient. If you don’t control the database completely, then the Tuplizer approach might solve some of your problems. But in that situation, you’ll probably have more things to worry about than just the validity of value objects

In my opinion, you cannot just assume that the database is correct. In 99% of applications concerning a database – some manual maintenance interaction with the database is required and just because the code guarentees value object validity when saved, you cannot assume the value object is correct.

A value type should always be in a valid state – Not validating that the type being read from the database is valid means you cannot stand over your applications value types being in a valid state!

We got around this by using PostLoadEventListener – where ctor with guard clauses is called.

So, if your code can guarantee that no invalid value objects are persisted, then you can still perform all the necessary guard checks in your own constructor, which would be the only one your code can use (since the default constructor would be private) and then you’d never have invalid value objects.

i believe you can avoid the need for a default constructor by using a Tuplizer, but i can’t immediately find a good link on that

about the validation… i guess it depends, if you need to validate each property on its own, you could tell nhibernate to map against private setters in the value type instead of private fields. In that case, the setters could perform some kind of basic evaluation. If you need to validate them together, then you’ll either need a custom validation method or you might get it done using the Tuplizer solution.

I agree that NH doesn’t offer 100% persistence ignorance… but i do think it’s about as close as you’ll come outside of rolling your own

I have spent a good amount of time researching the use of “immutable types” with NHibernate see http://forum.hibernate.org/viewtopic.php?p=2392717
http://unhandled-exceptions.com/blog/index.php/2008/08/04/summer-of-nhibernate-session-07-exploring-mn-relationships-views-and-components/ (see comment at end)

In my opinion NHibernate + true DDD dont really fit easily!

You mention that there is a workaround to not use the default constructor. Can you elaborate a little more on this? In my opinion, in a DDD world, the domain must be completely persistence ignorant – the default constructor breaks that!

Also, we strive to ensure that all value types are in a valid state so we validate our type by performing guard checks in the ctor(within the ctor which takes in the args!). Do you not validate your value types?

This becomes even more problematic when you are retrieving a value type from the database – NHibernate instantiates the type using default ctor and sets the types properties through reflection. At the moment we use a PostLoadEventListener implementation where the constructor that has arguments is called instead. If one of the guard checks fail we throw an exception.

that’s a nice approach… the default Equality and GetHashCode implementations will probably be good enough for most cases, and for those where you need better performance of Equals and GetHashCode, you can still provide an overridden optimized implementation.

I’m sure by doing that God killed a kitten somewhere, but it’s worked out well and is slightly more normalized than mapping as Components.