Property values must be stored somewhere. In a typical object property, values are stored in backing fields, which are simply private fields declared in the class—for example:

private string _name = string.Empty;
  private int _id;

If you use the compact property declaration syntax, the compiler will create a hidden private backing field on your behalf.

public string Name { get; set; }

In this case, you don't know or care about the field name, but the field is there nonetheless.

CSLA .NET allows you to use private backing fields if you would like, or you can allow CSLA .NET to manage the field values automatically.

Using private backing fields offers better performance, but it does require that you declare and initialize the backing field in your code. Managed backing fields incur a performance penalty, because CSLA .NET is actually storing the field values in a collection on your behalf, but they require less code in your business class.

You can use private backing fields for any field value required by your object. However, when it comes to storing references to child objects, I strongly recommend using managed backing fields. I'll discuss storing child references later in the chapter, as they are relatively complex. If you choose to store child references in private backing fields, then you'll have to deal with all that complexity yourself. On the other hand, a managed backing field takes care of everything automatically.

As with many features of CSLA .NET, you can choose which technique suits your needs best. In general, I typically use managed backing fields and only switch to private backing fields when dealing with large collections of objects where performance is a bigger issue.

Private Backing Fields

The four property helper methods have overloads that accept private backing fields as parameters. For example, you can call GetProperty() like this:

private static PropertyInfo<string> NameProperty =
    RegisterProperty(new PropertyInfo<string>("Name"));
  private string _name = NameProperty.DefaultValue;
  public string Name
  {
    get { return GetProperty(NameProperty, _name); }
    set { SetProperty(NameProperty, ref _name, value); }
  }

The bold lines indicate the differences with the previous example code. Notice that a field is now declared explicitly and is initialized to a default value.

Also notice how the field is passed as a parameter to GetProperty(). As you can imagine, GetProperty() simply returns the value as a result, but only after checking authorization rules.

The SetProperty() method is more interesting, because the field is passed as a parameter using the ref qualifier. This means the field is passed by reference, so any changes you make to the field inside the SetProperty() method will actually change the value of the field itself.

In this case, SetProperty() still performs the steps shown in Figures 7-1 and 7-2, but if the property's value is ultimately changed, the new value will be put directly into that field, which is passed by reference.

Private Backing Fields with Type Conversion

There are variations on the four property helper methods that can be used to help convert a field from one type to another. For example, you may maintain the field value as an enum or SmartDate type, but declare the property itself to be of type string. This is useful when the user wants to see a friendly name, but the object wants a more computer-friendly data type for the property.

private static PropertyInfo<SmartDate> BirthDateProperty =
    RegisterProperty(new PropertyInfo<SmartDate>("BirthDate"));
  private SmartDate _birthDate = BirthDateProperty.DefaultValue;
  public string BirthDate
  {
  get { return GetPropertyConvert<SmartDate, string>(
    BirthDateProperty, _birthDate); }
  set { SetProperty<SmartDate, string>(
    BirthDateProperty, ref _birthDate, value); }
  }

Rather than calling GetProperty(), this code calls GetPropertyConvert(), which takes two type parameters. The first is the type of the backing field, and the second is the type of the property. The GetPropertyConvert() method is implemented in BusinessBase like this:

protected P GetPropertyConvert<F, P>(PropertyInfo<F> propertyInfo, F field)
  {
    return Utilities.CoerceValue<P>(
      typeof(F), null,
      GetProperty<F>(
         propertyInfo.Name, field, propertyInfo.DefaultValue,
        Security.NoAccessBehavior.SuppressException));
  }

This method delegates the task of getting the field value to the GetProperty() method you've already seen. However, it then uses Utilities.CoerceValue() to coerce the value to the specified property type.

You might wonder how this differs from just using a cast to change the value type. The CoerceValue() method attempts to perform a cast, but it's more aggressive and attempts other techniques of type conversion as well, including using .NET type converters. It also includes functionality to convert enum types into and out of text representations.

The end result is that these versions of the four property helper methods can save you a lot of code and complexity in cases where the property type and backing field type do not match.

Managed Backing Fields

My first property example illustrated how to declare a property that uses a managed backing field.

private static PropertyInfo<string> NameProperty =
    RegisterProperty(new PropertyInfo<string>("Name"));
  public string Name
  {
    get { return GetProperty(NameProperty); }
    set { SetProperty(NameProperty, value); }
  }

Notice that no private field is declared, so there's no field to pass to the GetProperty() or SetProperty() method. Behind the scenes, the field manager stores and retrieves the value from a data structure. I'll discuss the field manager in more detail later.

Managed Backing Fields with Type Conversion

As with private backing fields, four methods get and set managed property values while converting the value to different types. The syntax is similar to what you've already seen.

private static PropertyInfo<CategoryEnum> CategoryProperty =
    RegisterProperty(new PropertyInfo<CategoryEnum>("Category"));
  public string Category
  {
  get { return GetPropertyConvert<CategoryEnum, string>(CategoryProperty); }
  set { SetPropertyConvert<CategoryEnum, string>(CategoryProperty, value); }
  }

Again, rather than calling GetProperty() or SetProperty(), similar methods are called such as GetPropertyConvert(). These methods take two type parameters; the first is the type of the field value, and the second is the type of the property. The GetPropertyConvert() overload looks like this:

protected P GetPropertyConvert<F, P>(
    PropertyInfo<F> propertyInfo, Security.NoAccessBehavior noAccess)
  {
    return Utilities.CoerceValue<P>(
      typeof(F), null, GetProperty<F>(propertyInfo, noAccess));
  }

As with the earlier overload, this one gets the value and then passes it to Utilities.CoerceValue() to coerce the value to a different type.

Child Object Reference Fields

Business objects can contain other business objects. As discussed in Chapter 4, the containing object is a parent object, and the contained object is a child object. In this case, the parent object maintains a reference to the child object.

I'll discuss the issues around parent-child relationships in Chapter 9. For now, you should know that the normal way to create a property that references a child object is to write code like this in your parent object:

private static PropertyInfo<ChildType> ChildProperty =
    RegisterProperty(new PropertyInfo<ChildType>("Child"));
  public ChildType Child
  {
    get
    {
      if (!FieldManager.FieldExists(ChildProperty))
        LoadProperty(ChildProperty, ChildType.NewChild());
      return GetProperty(ChildProperty);
    }
  }

This stores the child reference in a managed backing field, which allows the field manager to automatically take care of all the housekeeping details involved with a child reference.

The RegisterProperty() and GetProperty() calls should be familiar by this point. But these two lines are new:

if (!FieldManager.FieldExists(ChildProperty))
        LoadProperty(ChildProperty, ChildType.NewChild());

The first line uses the FieldManager to determine if this child object has been created. If it has not, then the second line uses LoadProperty() to add a new instance of the object as a child. The call to ChildType.NewChild() is invoking the child object's factory method, which is a concept I discussed in Chapters 4 and 5.

This relatively simple-looking code is hiding some fairly complex object interactions, and I'll discuss them later in Chapter 9 when I cover parent-child relationships.

If you look closely at the way RegisterProperty() is called in the example code in this chapter, you'll see that it is called while initializing a static field.

private static PropertyInfo<string> NameProperty =
    RegisterProperty(new PropertyInfo<string>("Name"));

It makes sense that your properties need to be registered with CSLA .NET before they can be used, and if your business class inherits directly from BusinessBase or ReadOnlyBase, then this will happen automatically. The reason is that any attempt to get or set a property will call the GetProperty() or SetProperty() method, which accepts the PropertyInfo field as a parameter—for example:

return GetProperty(NameProperty);

Any attempt to access a static field forces .NET to initialize all the static fields declared in that class.

However, if you use inheritance such that your business class inherits from a class that, in turn, inherits from BusinessBase or ReadOnlyBase, then things will get more complex. This is because of the way .NET initializes static fields, which turns out to be complex and counterintuitive.

The .NET runtime only initializes the static fields for a class when one of the static fields on that class is accessed (read or changed), or if the class has a static constructor. To be very clear, this means that instance methods and properties can be called before the static fields are initialized.

Unless you are absolutely sure that a static field from every class in the inheritance hierarchy has been accessed, you can't be sure that all the static fields have been initialized. The end result is that your properties might be accessed before they have all been registered, which will ultimately cause the field manager to throw an exception.

You can use one of two techniques to prevent this issue. You can add a static constructor to each of your custom base classes, or you can ensure that some static field is initialized as each object instance is created.

Adding a static Constructor

Adding a static constructor is easy—for example:

[Serializable]
  public abstract class CustomBase<T> : BusinessBase<T>
    where T : CustomBase<T>
  {
  static CustomBase()
  { }
  }

All static fields are initialized before the static constructor executes, so adding this bit of code ensures that the static fields in this class will be initialized before an instance of this class, or a subclass, can be created.

The downside to this is a performance impact. When you declare a static constructor in a class, the compiler injects code everywhere any method of this class is accessed, checking to ensure that the static constructor has been run before any other code. Obviously, all this extra checking can have a negative impact on performance.

It is actually slightly worse than this, because the compiler also injects code to ensure that the static constructor is only called exactly once, even in a multithreaded environment. So the code it injects is relatively complex and involves potential locking.

Initializing a Dummy static Field

An alternative to declaring a static constructor is to ensure that at least one static field is accessed in each class before an instance of that class, or a subclass, is created. You can do this by declaring a static field in every class and initializing it any time an instance of the object is created.

The trick is to remember that the .NET Framework creates instances two ways. Normal creation of an instance invokes the constructor of each class in the inheritance hierarchy, but deserialization (when using the BinaryFormatter or NetDataContractSerializer) doesn't invoke any constructors.

Fortunately, the BusinessBase and ReadOnlyBase classes include code, so they are notified when they are deserialized. In that case, they invoke a protected method called OnDeserialized(), which a business class can override to be notified that it has been deserialized.

Using this capability, you can force initialization of the static fields in a class by adding the following code to all your business and base classes when using a custom base class:

[Serializable]
  public abstract class CustomBase<T> : BusinessBase<T>
    where T : CustomBase<T>
  {
  private static int _forceInit;

  public CustomBase()
  {
    _forceInit = 1;
  }

  protected override void OnDeserialized(StreamingContext context)
  {
    _forceInit = 1;
  }
  }

When an instance of this class, or a subclass, is created normally, the constructor is invoked. The constructor accesses the static field and ensures that all static fields are initialized. When an instance is created through deserialization, OnDeserialized() is invoked, which again accesses the static field and ensures that all static fields are initialized.

This technique requires a bit more code, but it doesn't incur the performance penalty of implementing a static constructor.

Regardless of which technique you use, the end result is that the static fields declared in each class are initialized before any properties can be accessed. This ensures that all the RegisterProperty() calls occur and that all properties are registered early in the process.

The BusinessBase and ReadOnlyBase classes expose a protected property named FieldManager to make the FieldDataManager available to the business object's code. For example, this code is in BusinessBase:

protected FieldManager.FieldDataManager FieldManager
  {
    get
    {
      if (_fieldManager == null)
      {
        _fieldManager = new FieldManager.FieldDataManager(this.GetType());
        UndoableBase.ResetChildEditLevel(
          _fieldManager, this.EditLevel, this.BindingEdit);
      }
      return _fieldManager;
    }
  }

This property is designed to only create an instance of the FieldDataManager on demand. The idea is that if your business class never uses any managed backing fields, no FieldDataManager object will be created. I chose to do this to minimize the overhead involved in creating a business object when managed fields aren't used.

This does complicate the use of the FieldManager property throughout the rest of BusinessBase and ReadOnlyBase. For example, BusinessBase includes this code:

public virtual bool IsDirty
  {
    get {
      return IsSelfDirty || (_fieldManager != null && FieldManager.IsDirty());
    }
  }

A parent object is considered dirty, or changed, if it or any of its child objects have been changed. To know if the object has been changed, the IsDirty property checks the FieldManager to find out if any managed fields or child objects have been changed. But before accessing the FieldManager property, it checks to see if the _fieldManager field is null. This prevents accidental creation of a FieldDataManager instance when there are no managed fields in the business object.

Getting back to the FieldManager property, you should see that a method called UndoableBase.ResetChildEditLevel() is called after the FieldDataManager instance is created. Technically, the FieldDataManager is a child object contained within the business object. Because it is a child object, its edit level for n-level undo must be kept in sync with the business object itself.

I'll discuss the concept of edit levels in Chapter 11. For now, it is enough to know that the ResetChildEditLevel() call ensures that the new child object is in sync with its parent.

The FieldDataManager class itself is relatively complex. Each instance of this class is a child of a business object. Also, because the field manager is responsible for storing the values of the business object's properties, it must participate in the n-level undo process discussed in Chapter 11. Here's the declaration of the class:

[Serializable()]
  public class FieldDataManager : IUndoableObject, IMobileObject

The class is Serializable, because the data it contains may be serialized when the business object is cloned or moved across the network between a client and application server. It implements the IUndoableObject interface because it must participate in the n-level undo behaviors covered in Chapter 11.

The field manager's primary job is to maintain the values of all properties that use managed backing fields. Simplistically, it might seem that you could store these values in a Dictionary, keyed off the property name. That would work technically, but accessing elements in a Dictionary turns out to be a relatively slow operation.

Instead, the field values are maintained in an array of IFieldData objects.

private IFieldData[] _fieldData;

I'll discuss the IFieldData interface later. For now, I want to discuss how the property values are indexed into this array.

Generating a Consolidated Property List

What algorithm is used to set and get property values from this array in a meaningful manner? In short, each property is assigned a numeric index value between 0 and the number of properties registered for the business object type. Assigning these index values is the challenge, and it is complicated by inheritance.

Earlier in the chapter, I discussed the PropertyInfoManager and how it maintains a list of IPropertyInfo objects for each business object type. Remember that a business object type might be a subclass of some other type. It turns out that any level in the inheritance hierarchy might declare a property and register it by calling RegisterProperty().

This means that to get a consolidated list of all properties declared by a business object, it is necessary to walk through all the types in the inheritance hierarchy, getting the list of IPropertyInfo objects for each of the types. Obviously, that process could be relatively expensive, so it is done only once and the result is cached. FieldDataManager includes a GetConsolidatedList() method that retrieves the consolidated list of properties if it has already been generated, or calls CreateConsolidatedList() to create the list.

The CreateConsolidatedList() method is the interesting part of this process, because it assembles the consolidated list and assigns the numeric index values. Here is the method from the FieldDataManager class:

private static List<IPropertyInfo> CreateConsolidatedList(Type type)
  {
    List<IPropertyInfo> result = new List<IPropertyInfo>();
    // get inheritance hierarchy
    Type current = type;
    List<Type> hierarchy = new List<Type>();
    do
    {
      hierarchy.Add(current);
      current = current.BaseType;
    } while (current != null && !current.Equals(typeof(BusinessBase)));
    // walk from top to bottom to build consolidated list
    for (int index = hierarchy.Count - 1; index >= 0; index—)
      result.AddRange(
        PropertyInfoManager.GetPropertyListCache(hierarchy[index]));
    // set Index properties on all unindexed PropertyInfo objects
    int max = −1;
    foreach (var item in result)
    {
      if (item.Index == −1)
      {
        max++;
        item.Index = max;
      }
      else
      {
        max = item.Index;
      }
    }
    // return consolidated list
    return result;
  }

There's a lot going on here, so let's break it down. The first step is to get a list of all the types in this object's inheritance hierarchy.

Type current = type;
      List<Type> hierarchy = new List<Type>();
      do
      {
        hierarchy.Add(current);
        current = current.BaseType;
      } while (current != null && !current.Equals(typeof(BusinessBase)));

Since the FieldDataManager and the RegisterProperty() methods are declared in the BusinessBase class, there's no sense going any higher than that class. The result of this code is that the hierarchy field has a list of the types in this inheritance hierarchy, with the top-most base class being the last item in the list.

The next step is to loop through all those types, getting the list of any registered properties for each type. This is done from top to bottom, so the deepest base class is processed first.

for (int index = hierarchy.Count - 1; index >= 0; index—)
        result.AddRange(
          PropertyInfoManager.GetPropertyListCache(hierarchy[index]));

Remember that the registered properties for each type are stored in sorted order, so this algorithm guarantees that you end up with a consolidated list in the result field, where the IPropertyInfo objects are sorted within each type, and where the list starts with the deepest base type and moves out to end with the actual business object type.

Since the order is known and consistent in all cases, it is then possible to loop through all the IPropertyInfo objects and assign them a numeric index value, starting at 0 and counting up.

int max = −1;
    foreach (var item in result)
    {
      if (item.Index == −1)
      {
        max++;
        item.Index = max;
      }
      else
      {
        max = item.Index;
      }
    }

Of course, the value is only set if it hasn't been set to start with. In the PropertyInfo class, the index value is initialized to -1, and this loop only changes the value if it is still set to that initial default. This is important, because a given base class could be the base class for numerous business classes, and the index values for that base class should only be set once.

The end result of this work is that there's a consolidated list of all registered properties for the business object type, that those properties are in a consistent order, and that each IPropertyInfo object has a unique numeric index value that you can use to index into the array of IFieldData objects where the actual object's field data is stored.

IFieldData and IFieldData<T> Interfaces

Each field value is stored in an object that implements the IFieldData interface. In other words, each field value is stored in an object that maintains the field value, along with some metadata about the field value.

That interface is declared like this:

public interface IFieldData : ITrackStatus
{
  string Name { get; }
  object Value { get; set; }
  void MarkClean();
}

This interface ensures that each field is stored in an object that exposes the name of the field and the field's value and allows the field to be marked as being unchanged.

This interface inherits from ITrackStatus, which I'll discuss in Chapter 6 and will cover in depth in Chapter 8. The result is that any IFieldData is guaranteed to expose status tracking properties such as IsDirty and IsValid.

There's also a generic version of the interface.

public interface IFieldData<T> : IFieldData
{
  new T Value { get; set; }
}

This generic interface simply extends the interface with a strongly typed Value property that replaces the loosely typed one.

The reason for the generic interface is performance. Most field values are value types, such as int, float, and DateTime. If you store such values in a field of type object, .NET will do what is called boxing and unboxing, meaning that the value will be converted into and out of being an object rather than being a simple value type.

The field manager always attempts to store values in an IFieldData<T> first, only falling back to an IFieldData if necessary. This helps avoid the cost of boxing and unboxing value types.

FieldData<T> Class

Now that you've seen the IFieldData and IFieldData<T> interfaces, it should come as no surprise that the framework includes a default implementation. Only IFieldData<T> is implemented in the framework, because the field manager always stores values using a strongly typed approach.

The primary purpose of the FieldData class is to store a field value, along with important metadata about that field. In particular, it also stores the field's name, type, and a flag indicating whether the field has been changed.

The implementation provided by FieldData is designed for performance over advanced functionality. For example, it determines whether a field has been changed by maintaining a simple flag that is set to true any time the value is changed.

public virtual T Value
  {
    get
    {
      return _data;
    }
    set
    {
      _data = value;
      _isDirty = true;
    }
  }

Even if the field is reset later to its original value, it is considered to have changed. While this is somewhat simplistic, it is also fast and minimizes resource overhead. The primary alternative would be for the object to maintain a copy of the field's original value so it can compare any new value to that original value to decide whether IsDirty should return true or false. Obviously, that would double the amount of memory required by each FieldData object and would double the amount of data transferred across the network in client/server scenarios.

You should now understand that the FieldDataManager maintains a list of field values in an array of IFieldData, where the objects are of type FieldData<T>. To conclude this topic, I want to discuss how framework classes retrieve and set the field values.

Getting Field Values

The FieldDataManager class exposes a GetFieldData() method that other framework classes can use to retrieve field values.

internal IFieldData GetFieldData(IPropertyInfo prop)
  {
    try
    {
      return _fieldData[prop.Index];
    }
    catch (IndexOutOfRangeException ex)
    {
      throw new InvalidOperationException(Resources.PropertyNotRegistered, ex);
    }
  }

This method simply uses the index from the IPropertyInfo parameter to find and return the IFieldData object from the array.

The interesting part of this method is the exception handling. Notice how any IndexOutOfRangeException is converted into the more useful InvalidOperationException, with the default message text of "One or more properties are not registered for this type." The most common issue people face when using managed fields is that they register the property incorrectly. The normal result would be an unintuitive IndexOutOfRangeException, so this code ensures that the business developer will get a more useful exception and message.

A field value is retrieved because BusinessBase or ReadOnlyBase needs the value. This means that GetFieldData() is invoked from a GetProperty() or ReadProperty() method in one of those classes. For example, here's the ReadProperty() method in BusinessBase, with the call to GetFieldData() and related code highlighted:

protected P ReadProperty<P>(PropertyInfo<P> propertyInfo)
    {
      P result = default(P);
    FieldManager.IFieldData data = FieldManager.GetFieldData(propertyInfo);
    if (data != null)
    {
      FieldManager.IFieldData<P> fd = data as FieldManager.IFieldData<P>;
      if (fd != null)
        result = fd.Value;
      else
        result = (P)data.Value;
    }
      else
      {
        result = propertyInfo.DefaultValue;
        FieldManager.LoadFieldData<P>(propertyInfo, result);
      }
      return result;
    }

The GetFieldData() method is called to get the IFieldData object from the field manager. Assuming there is a corresponding field, the code then attempts to cast the result to an IFieldData<P> to use the strongly typed interface.

FieldManager.IFieldData<P> fd = data as FieldManager.IFieldData<P>;
        if (fd != null)
          result = fd.Value;

This is always the case when using the default FieldData<T> type provided by CSLA .NET, so the field value will be returned without boxing or unboxing.

If a person has implemented his own IFieldData that doesn't use the generic interface, then the boxed value must be converted to the right type and returned.

else
          result = (P)data.Value;

BusinessBase and ReadOnlyBase use this technique when they need to retrieve managed field values.

Setting Field Values

FieldDataManager has two SetFieldData() methods: one generic and one not. The default is to use the generic overload, which looks like this:

internal void SetFieldData<P>(IPropertyInfo prop, P value)
  {
    var field = GetOrCreateFieldData(prop);
    var fd = field as IFieldData<P>;
    if (fd != null)
      fd.Value = value;
    else
      field.Value = value;
  }

This code retrieves (or creates) the IFieldData object from the array, then attempts to cast it to an IFieldData<T>. Normally this will succeed, because the storage object is a FieldData<T>. It's then possible to store the field value without boxing or unboxing.

The other overload is loosely typed, so it would incur boxing and unboxing costs. Even more, it will do type coercion if needed.

internal void SetFieldData(IPropertyInfo prop, object value)
  {
    Type valueType;
    if (value != null)
      valueType = value.GetType();
    else
      valueType = prop.Type;
    value = Utilities.CoerceValue(prop.Type, valueType, null, value);
    var field = GetOrCreateFieldData(prop);
    field.Value = value;
  }

This overload accepts the input value, then uses the CoerceValue() method to convert the value to the type expected by the field. Normally, you would expect that the inbound value is the same type (in which case CoerceValue() would do no work), but it is possible for a business object author to provide a value of some other type. This helps ensure that the value is converted to the right type before it is stored.

Only BusinessBase supports read-write properties, so only BusinessBase calls these methods. For example, here's the LoadProperty() method from BusinessBase:

protected void LoadProperty<P>(PropertyInfo<P> propertyInfo, P newValue)
  {
    try
    {
      P oldValue = default(P);
      var fieldData = FieldManager.GetFieldData(propertyInfo);
      if (fieldData == null)
      {
        oldValue = propertyInfo.DefaultValue;
        fieldData = FieldManager.LoadFieldData<P>(propertyInfo, oldValue);
      }
      else
      {
        var fd = fieldData as FieldManager.IFieldData<P>;
        if (fd != null)
          oldValue = fd.Value;
        else
          oldValue = (P)fieldData.Value;
      }
      LoadPropertyValue<P>(propertyInfo, oldValue, newValue, false);
    }
    catch (Exception ex)
    {
      throw new PropertyLoadException(
        string.Format(Properties.Resources.PropertyLoadException,
                                propertyInfo.Name, ex.Message));
    }
  }

The majority of this method is centered around retrieving the value from the field manager. It calls GetFieldData() to get the IFieldData object, and then it sets the oldValue field either to some default value or to the value retrieved from the field manager.

All that work is in preparation for a call to LoadPropertyValue(), which does the real work. The complex LoadPropertyValue() method implements the flowchart shown earlier in Figure 7-2. You can look at the full code from the Source Code/Download area of the Apress website (www.apress.com). The key thing to recognize is that it ultimately calls the SetFieldData() method from the field manager:

FieldManager.SetFieldData<P>(propertyInfo, newValue);

Throughout the entire process, the input value is strongly typed, including during the call to the field manager and storage in the FieldData<T> object.

You may be wondering, then, where that non-generic SetFieldData() overload is invoked. It is invoked from a non-generic overload of SetProperty() implemented in BusinessBase.

protected void SetProperty(IPropertyInfo propertyInfo, object newValue)
  {
    FieldManager.SetFieldData(propertyInfo, newValue);
  }

This overload of SetProperty() exists to support scenarios in which the business developer is loading the fields of the object from an external data source, such as an XML file or database. In that case, the developer might be looping through all the registered properties, loading the field data for each one, and would be unable to use a generic method in that case. Additionally, the input values may or may not be an exact match for the type of the field, which is why it is so important that the SetFieldData() method call CoerceValue() to convert the value to the right type.

At this point, you should have an understanding of how managed backing fields are implemented, including their storage in IFieldData objects, which are managed by the FieldDataManager and consumed in BusinessBase and ReadOnlyBase.