If I have this simple class...

public class Foo
{
[id-stuff]

private int _bar;
public virtual int Bar
{
get
{
return _bar;
}
}
}

...and map it something like this...
<?xml version="1.0" encoding="utf-8" ?>
<hibernate-mapping xmlns="urn:nhibernate-mapping-2.2"
assembly="xxx"
namespace="xxx"
default-access="field.camelcase-underscore">
<class name="Foo">
[id-stuff]
<property name="Foo" />
</class>
</hibernate-mapping>

...a proxy default will be created (I'm using version 1.2 where lazy loading is on by default) when recreating the entity from datasource. Fine. However - I'm a bit confused what happen if I set the _bar field using reflection in a Foo instance? These changes cannot be seen in its property. I can see the reason behind it, while not working towards a Foo instance but a proxy and this proxy obviously don't pick up changes to the underlying field at run-time.

I've tried to experiment in what situation this will lead to unwanted behaviour? Is setting the (private) field a no-no when working with proxies? Or will the changes always be included when later persisted?
What is the best practise here? If you want a property with no setter but in some rare situation you still need to be able to change it - what to do using nhib + lazy loading?

Any ideas?
Thanks, Roger

Have you tried using a protected setter and then setting the property through reflection instead of the field? That way the proxy's setter should get called ...

Absolutly, that will work. I'm a bit uncertain though when you can trust the "reflections directly against fields" will work or not.

I assume the issue isn't the persistence of the value, but having the proxy know that the object needs to be lazy loaded if you just have a proxy? I believe it will work fine if the object is already loaded.

That being said, I typically take a different approach. Instead of using a field accessor, I use an explicitly implemented interface. The main property only has a getter, but a property of the same name exists on the interface as well which happens to have a setter. NHibernate will automatically first check to see if there is a property which exists for the name you gave it, if there is no getter or setter for that property name it checks all explicitly implemented interfaces and uses the getter or setter of that interface if the property name matches. It's very simple to use, and works well.

Then within your code you could actually cast your object as the interface you are using and access the property that way. This way you could change the value of your "read-only" property without using reflection. Normal action won't be to cast your object as an interface to set a value, so typical usage should still be read-only. It's a little bit more work, but overall seems a little clearer to me. That being said I also understand the argument of cluttering up the objects with basically unnecessary interfaces.