CODEWITHSUNDEEP
wpfimmutability
Jacob Stanley
Jacob Stanley

Reputation: 4824

How can I edit immutable objects in WPF without duplicating code?

We have lots of immutable value objects in our domain model, one example of this is a position, defined by a latitude, longitude & height.

/// <remarks>When I grow up I want to be an F# record.</remarks>
public class Position
{
    public double Latitude
    {
        get;
        private set;
    }

    // snip

    public Position(double latitude, double longitude, double height)
    {
        Latitude = latitude;
        // snip
    }
}

The obvious way to allow editing of a position is to build a ViewModel which has getters and setters, as well as a ToPosition() method to extract the validated immutable position instance. While this solution would be ok, it would result in a lot of duplicated code, especially XAML.

The value objects in question consist of between three and five properties which are usually some variant of X, Y, Z & some auxiliary stuff. Given this, I had considered creating three ViewModels to handle the various possibilities, where each ViewModel would need to expose properties for the value of each property as well as a description to display for each label (eg. "Latitude").

Going further, it seems like I could simplify it to one general ViewModel that can deal with N properties and hook everything up using reflection. Something like a property grid, but for immutable objects. One issue with a property grid is that I want to be able to change the look so I can have labels and textboxes such as:

Latitude:   [      32 ]  <- TextBox
Longitude:  [     115 ]
Height:     [      12 ]

Or put it in a DataGrid such as:

Latitude  |  Longitude  |  Height
      32           115         12

So my question is:

Can you think of an elegant way to solve this problem? Are there any libraries that do this or articles about something similar?

I'm mainly looking for:

Upvotes: 12

Views: 1825

Answers (3)

jwrush
jwrush

Reputation: 753

I found this old question while researching my possible options in the same situation. I figured I should update it in case anyone else stumbles on to it:

Another option (not available when Paul offered his solution since .Net 4 wasn't out yet) is to use the same strategy, but instead of implementing it using CustomTypeDescriptors, use a combination of generics, dynamic objects and reflection to achieve the same effect.

In this case, you define a class

class Mutable<ImmutableType> : DynamicObject
{
   //...
}

It's constructor takes an instance of the immutable type and a delegate that constructs a new instance of it out of a dictionary, just like in Paul's answer. The difference here, however, is that you override the TryGetMember and TrySetMember to populate an internal dictionary that you're eventually going to use as the argument for the constructor-delegate. You use reflection in order to verify that the only properties that you're accepting are those that are actually implemented in ImmutableType.

Performance wise, I wager that Paul's answer is faster, and doesn't involve dynamic objects, which are known to put C# developers into fits. But the implementation for this solution is also a little simpler, because Type Descriptors are a bit arcane.

Here's the requested proof-of-concept / example implementation:

https://bitbucket.org/jwrush/mutable-generic-example

Upvotes: 2

Paul Stovell
Paul Stovell

Reputation: 32725

Custom Type Descriptors could be used to solve this problem. Before you bind to a Position, your type descriptor could kick in, and provide get and set methods to temporarily build the values. When the changes are committed, it could build the immutable object.

It might look something like this:

DataContext = new Mutable(position, 
    dictionary => new Position(dictionary["lattitude"], ...)
);

Your bindings can still look like this:

<TextBox Text="{Binding Path=Lattitude}" />

Because the Mutable object will 'pretend' to have properties like Lattitude thanks to its TypeDescriptor.

Alternatively you might use a converter in your bindings and come up with some kind of convention.

Your Mutable class would take the current immutable object, and a Func<IDictionary, object> that allows you to create the new immutable object once editing completes. Your Mutable class would make use of the type descriptor, which would create PropertyDescriptors that create the new immutable object upon being set.

For an example of how to use type descriptors, see here:

http://www.paulstovell.com/editable-object-adapter

Edit: if you want to limit how often your immutable objects are created, you might also look at BindingGroups and IEditableObject, which your Mutable can also implement.

Upvotes: 5

HolisticElastic
HolisticElastic

Reputation: 967

Can you think of an elegant way to solve this problem?

Honestly, you just dance around the problem, but don't mention the problem itself ;).

If I correctly guess your problem, then the combination of MultiBinding and IMultiValueConverter should do the trick.

HTH.

P.S. BTW, you have immutable class instances, not value objects. With value objects (which are described by struct keyword) you would dance much more no matter if there were setters or not :).

Upvotes: 0

Related Questions