Not-Null constraints in POCO Objects

Answer 1

There are a few ways of doing this depending on your POCO behaviour and coding style. Firstly, you could use nullable types to express that this field is nullable and it would therefore be implicit that the rest are not nullable. Alternatively you could introduce a Phone value type as the type for the Phone property of the POCO you illustrated, implying that because it is not a primitive type it is "more important" - this would also enable you to encapsulate phone number validation within the class itself.

In my mind, to be a true POCO object, it need not worry about the underlying nullability within the database table it is persited in... it should actually have validation and value types that express its behaviour as a stand alone entity; thus before it gets to NHibernate it is already in a valid state.

Answer 2

Make notnull properties readonly and write to them via a public constructor. Make the default constructor protected or private.

public class DomainObject{
private string nnp;
protected DomainObject(){}
public DomainObject(string nnp){
this.nnp = nnp;
}
public string NotNullProp {get {return nnp;}}
public string NullableProp {get;set;} 
}