Question

Is there any way to access the backing field for a property in order to do validation, change tracking etc.?

Is something like the following possible? If not is there any plans to have it in .NET 4 / C# 4?

public string Name {     get;     set     {         if (value != <Keyword>)         {             RaiseEvent();         }         <Keyword> = value;     } } 

The main issue I have is that using auto properties doesn’t allow for the same flexibility in validation etc. that a property with a explicit backing field does. However an explicit backing field has the disadvantage in some situations of allowing the class it is contained in to access the backing field when it should be accessing and reusing the validation, change tracking etc. of the property just like any other class that may be accessing the property externally.

In the example above access to the backing field would be scoped to the property thus preventing circumvention of the property validation, change tracking etc.

Edit: I’ve changed < Backing Field > to < Keyword >. I would propose a new keyword similar to value. field would do nicely although I’m sure it’s being used in a lot of existing code.

Answer 1

Having read your comments in Mehrdad’s answer, I think I understand your problem a bit better.

It appears that you are concerned about the ability of the developer to access private state in the class they are writing, bypassing your validation logic, etc. This suggests that the state should not be contained in the class at all.

I would suggest the following strategy. Write a generic class that represents a ValidatedValue. This class holds only the backing value and only allows access/mutation via get and set methods. A delegate is passed to the ValidatedValue to represent the validation logic:

public class ValidatedValue< T > {     private T m_val;     public ValidationFn m_validationFn;      public delegate bool ValidationFn( T fn );      public ValidatedValue( ValidationFn validationFn )     {         m_validationFn = validationFn;     }      public T get()     {         return m_val;     }      public void set(T v)     {         if (m_validationFn(v))         {             m_val = v;         }     } } 

You could, of course, add more delegates as required (eg, to support pre/post change notification).

Your class would now use the ValidatedValue in place of a backing store for your property.

The example below shows a class, MyClass, with an integer that is validated to be less than 100. Note that the logic to throw an exception is in MyClass, not the ValidatedValue. This allows you to do complex validation rules that depend on other state contained in MyClass. Lambda notation was used to construct the validation delegate – you could have bound to a member function instead.

public partial class MyClass {     private ValidatedValue<int> m_foo;      public MyClass()     {         m_foo = new ValidatedValue<int>(             v =>              {                 if (v >= 100) RaiseError();                 return true;             }         );     }      private void RaiseError()     {         // Put your logic here....         throw new NotImplementedException();     }      public int Foo     {         get { return m_foo.get(); }         set { m_foo.set(value); }     } } 

Hope that helps – somewhat off the original topic, but I think it’s more inline with your actual concerns. What we have done is taken the validation logic away from the property and put it on the data, which is exactly where you wanted it.