Why does NHibernate require "protected internal" visibility on auto properties?

Question

It used to be possible to map auto properties with private setters with NHibernate, but starting with version 3.2 this is no longer the case (not without replacing the entity validator), see NH dev discussion.

I understand the protected requirement, but why internal? This breaks encapsulation, and just feels dirty.

Is the only alternative going back to backing fields?

UPDATE: Embarassing but true, it turns out internal is not required. So, it's a toss-up between falling back to backing fields or using the protected setter and either avoiding setting values in the constructor or facing the risk of hard to track bugs. Thank you Fabio and @Nexus for pointing out my mistake.

Answer 1

Michael,

public string Foo { get; protected set; } should still be possible, the dev discussion is about public string Foo { get; private set; } which can lead to errors while using lazy properties.

Answer 2

NHibernate is quite dirty. It uses reflection in order to access the properties and fields.

You can even map private properties and fields as data points.

NHibernate ignores completely the visibility of the elements it needs to access.