In
part 2 of this LINQ 2 Reflection series I took you through how we go about querying fields that may existing within an object graph. Before we proceed, it’s important to remember that a call to object.Field<T> will return an instance of type Linq.Reflection.Field. As part 2 focused purely the reading fields it’s about time we take a look at how we can go about updating them. If we look at the intellisense that Visual Studio provides for the Field<T> class we can see that this class has an Update<T> method. Shown below.
Firstly, as the Update<T> method is contextual, there is no requirement to pass the name of the field we wish to update as this can be inferred from its parent. Secondly, As the Field<T> returns a
generic class of type T it also allows us to infer the Type of value we wish to update. Below is a simple update statement on a person entity.
person
.Field<string>("_firstName").Update("James")
.Field<string>("_lastName").Update("Brown")
.Field<DateTime>("_dateOfBirth").Update(DOB);
The Update<T> method of the Field<T> class returns an instance of the parent object we are currently working with. Internally the Field<T> class passes the parent context down our chained methods. Therefore we have the ability to move up the object graph if so desired. In this situation, where we are updating 1 of many fields on the parent context, its important that the return value from Update<T> is that of the parent object.
As that’s pretty much it for updating fields using LINQ to Reflection. You can call the Update<T> on and Field<T> or Property<T> accessor. As this point in our series you have the information you need to drill down any object reading and writing property/field values to suit your tests scenarios.
In part 4 we will start looking at how we can leverage the power of these extensions methods by showing how we can mock internal objects without breaking the rules of encapsulation.