One of the most major domain driven design principles is the concept of "persistence ignorance".
If you have entities in your domain that you want to persist through NHibernate, you must include a default constructor in the entity (although it can be private) - a small price to pay to use the power of NHibernate but persistence ignorance is broken (see following entity example):
public class SampleEntity
{
// Persistence ignorance broken...
private SampleEntity() { }
public void Method1()
{
. . .
}
}
When trying to convince the development team in my company to adopt NHibernate into the codebase, the default constructor requirement was a major stumbling block - as the domain was completely persistence ignorant!
Also, if you are developing a system where multiple threads of execution are in play regularly, making sure that all your value types are "immutable" avoids many concurrency issues. The problems working with immutable types and NHibernate are as follows:
1. Immutable types only work at a field level, not at a property level
2. Even if your types class is immutable (guard checks are performed via constructor), an invalid type can be retrieved back from the database (as the default constructor is called by NHibernate through reflection). There are ways around this using PostLoadEventListener to call the constructor with the guard checks is one solution - there are others
Has anyone else experienced the same proplems as described?
Posts
