Must Everything Be Virtual With NHibernate, Part III

Lame workaround, hmmm…

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.

OK. Better example.
But no reason you couldn’t just use a private property though ?

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?

Sorry, but this discussion is largely pointless, and your code sample is not what I would call best practice.
Just use interfaces together with the proxy keyword in the mapping, and don’t care about virtual or not virtual or some weird under-the-hood behaviour of dynamic proxies – it is a bad smell that the domain logic has to know about these issues at all!
And it’s in my experience also much better to let NH populate fields directly (via nosetter.camelcase) instead of using the relating properties, because the public properties of a business class will often have some additional validation or PropertyChanged logic, which I don’t want to be executed when only hydrating an entity from the DB. Besides all other things, this can lead to massive performance problems…
As you said, you also can hook your own IoC-Container into the proxy creation process, removing even the need for a default c’tor. But I don’t know yet if this is desirable in every case, since this may create other performance issues (IoC containers are very flexible, but also very slow…)

- Thomas

How can I code this example with NHibernate

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.

Thank you for replay. We use NHibernate for some time already. I got into trouble after trying upgrade to 2.1 release. My DAL objects has a few methods that marked as internal virtual. Idea behind it that I want restrict execution to my assemblies only for security reason. On top of it we obfuscate all internal marked stuff to add some extra trouble for people who wants to debug what we do. Now hibernate requires me to change all my

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?

Thank you for answer. We will set Lazy = false on all of our objects. As understand it will prevent NHibernate from generatig proxy on our objects. Correct if I am wrong, collections of child objects will be still lazy loaded. The difference will be that this collection will contains instances of object itself not proxies. I it right?