internal virtual SomeMethod(); into protected internal virtual and that I am trying to avoid doing this. I can make NHibernate to be “friend” of my assembly and in this case you should have no problem override my internal virtual stuff. Is it going to work?

you could just use the field access strategy

public class SomeObject
{
//Hibernate mapped field
protected virtual EncryptedDatabaseField { get; set; }

internal ClearTextField
{
get { return DecryptField(this.EncryptedDatabaseField); }
set { this.EncryptedDatabaseField = EncryptField(value); }
}
}

I simply trying to prevent see data ouside my assembly. If I will make ClearTextField “protected internal virtual” then it expose access to encryped database fields to anyone who can just simply subclass my class.

it really all depends on what you prefer… the whole point is that you can do pretty much everything that you prefer, with some very minor (IMO) constraints

- Thomas

1) i haven’t looked into the non-castle proxy generators, but the one for castle only requires that every non-private member is virtual and that you have a default constructor (it doesn’t even need to be public)
2) you can actually use your own proxy factory and generator… there is out-of-the-box support for Castle, LinFu and Spring. If you want your own proxy generator, you just need to provide an implementation… though i’m not entirely sure if all of the checks have been removed from the NHibernate codebase and have been moved into the specific proxy factories (though i guess they have been)

The reason I keep coming back to this point is that we’ve never needed this scenario. So making everything virtual has never seemed justifiable.
One of the reasons to switch to NHibernate is because of the very smart things it can do. But it’s difficult to to warrant touching all the persisted classes to make everything virtual in order to support a scenario we don’t (and probably won’t) ever use.

Two questions if I may:
1. Without studying the proxy generator. How do I gain some confidence that it “does the right thing” in _all_ circumstances?
2. Presumably there’s no reason why I can’t fork my own proxy generator that conforms to my property only scheme. Should be _much_ simpler right?

Regardless of what your personal preferences are, people will use backing fields for various reasons in their entities. The possibility of not initializing lazy-loaded values because of that, is something that an ORM should prevent.

“It has always just struck me as odd that I need to open up the API to my classes to satisfy the ORM.”

i find it just as odd that i would need to open up the data of my classes to _everyone_ because of a limitation in an ORM

I would still argue that the example is a little contrived to support the point. If I was reviewing this code I would say that the Customer property should be an auto-property like the rest.
I would argue that, in this code, referring to the backing field is a bug/smell/bad practice.

It has always just struck me as odd that I need to open up the API to my classes to satisfy the ORM.

I also find it hard to agree with your last point about blaming the ORM. I would suggest that these case were backing fields are accessed are smells. I would be looking to see where my code wasn’t conforming to the correct conventions not blaming the ORM for not being clever enough.

I’m playing devils advocate here. I am willing to be convinced.