How can I create a custom *write-only* dependency-property?

问题

I need to know what the procedure is for making a write-only dependency-property. I can see that the DependencyProperty class does not have a special "Register" method for write-only properties, but I have no idea whether the RegisterAttached method may apply to what I am trying to do.

This property needs to be a dependency-property, rather than a simple CLR property. Internally, my class requires a PropertyChangedCallback on this property in order to remain stable.

I know that write-only dependency-properties can be created, because it is stated quite clearly in:
Pro C# 2008 and the .NET 3.5 Platform, Page 1061.
However, this is the only place where I can even find "dependency property" and "write only" on the same page. And this author apparently did not think it was necessary to actually show the reader the procedure for anything other than a basic read-write dependency-property. Of course, this book could be a load of BS - but this book looks pretty standard, so I think it's a pretty safe bet that the author is correct. I assume the lack of information on the internet stems from the fact that nobody generally needs to make a property like this.

I know it sounds very questionable to want to make your own write-only dependency-property. I assure you it makes sense where I want it. My class has a property whose value is only useful to the object setting it. If another object were to request the value of this property later, it wouldn't be able to make any rational sense out of the value without knowing the original context of the setter.

This property is not intended to be used for informational purposes. Letting outside objects attempt to use the property value this way is problematic, dangerous, and a security risk. So I believe the best design is to prohibit read operations on this property. Anyone using my class will find that they are forced to use the class the way it was intended, which will work out much better and cleaner in the end.

回答1:

You can't, this appears to be by design. While I can understand your approach to the mentioned book and am in no way questioning its quality, I'd still presume this to be some sort of copy&paste or similar issue. Here is my reasoning:

WPF property system code

As you mentioned already the public API of the DependencyProperty Class only features RegisterReadOnly() and RegisterAttachedReadOnly().
Speluncing in the class internals via Reflector only reveals dedicated code for handling these Read-Only Dependency Properties, there is nothing in sight regarding write-only functionality.
Another option might have been metadata, but neither Dependency Property Metadata nor in particular Framework Property Metadata by means of the FrameworkPropertyMetadataOptions Enumeration is providing anything along the lines of write-only.

WPF property system design

More important, 'The current WPF implementation of its XAML processor is inherently dependency property aware. The WPF XAML processor uses property system methods for dependency properties when loading binary XAML and processing attributes that are dependency properties. This effectively bypasses the property wrappers.', see XAML Loading and Dependency Properties.
Most important, 'Dependency properties should generally be considered to be public properties. The nature of the Windows Presentation Foundation (WPF) property system prevents the ability to make security guarantees about a dependency property value.', see Dependency Property Security.

Especially the latter two points are outlining the design constraint, that dependency property values are always accessible via GetValue()/SetValue(), no matter whether their CLR wrappers are access restricted or available at all, with the only exception being the specifically accounted for Read-Only Dependency Properties.

Consequently, as Jeffs answer implies already, just removing the getter for example does not really prevent anyone accessing the property via GetValue(), though this may at least 'reduce the immediately exposed namespace of a custom class'. The usefulness of any such semantic workaround of making the property value somewhat less visible/accessible and the retrieved value inherently useless for clients as suggested by Jeff depends on your particular scenario of course.

回答2:

Interesting, this is definitely a rare scenario, I'd be interested to hear more in what it enables.

Would you consider the idea of providing an invalid value (such as null) for reads through binding or GetValue, while just not having a CLR getter?

Either use a private DependencyProperty to store the "real" value you care about, or just a private member variable.

In the property changed callback, always revert the value back to the original value, while storing away the new value that was set.

I spend most of my time doing Silverlight control development now, so this property works in WPF and Silverlight-land, and doesn't use coercian or anything fun like that. Maybe it gets you going on the right track, though.

    /// <summary>
    /// Sets the write-only dependency property.
    /// </summary>
    public string MyWriteOnlyDependencyProperty
    {
        set { SetValue(MyWriteOnlyDependencyPropertyProperty, value); }
    }

    private string _theRealSetValue;

    private bool _ignorePropertyChange;

    /// <summary>
    /// Identifies the MyWriteOnlyDependencyProperty dependency property.
    /// </summary>
    public static readonly DependencyProperty MyWriteOnlyDependencyPropertyProperty =
        DependencyProperty.Register(
            "MyWriteOnlyDependencyProperty",
            typeof(string),
            typeof(TemplatedControl1),
            new PropertyMetadata(null, OnMyWriteOnlyDependencyPropertyPropertyChanged));

    /// <summary>
    /// MyWriteOnlyDependencyPropertyProperty property changed handler.
    /// </summary>
    /// <param name="d">TemplatedControl1 that changed its MyWriteOnlyDependencyProperty.</param>
    /// <param name="e">Event arguments.</param>
    private static void OnMyWriteOnlyDependencyPropertyPropertyChanged(DependencyObject d, DependencyPropertyChangedEventArgs e)
    {
        TemplatedControl1 source = d as TemplatedControl1;
        if (source._ignorePropertyChange)
        {
            source._ignorePropertyChange = false;
            return;
        }
        string value = e.NewValue as string;

        source._theRealSetValue = value;

        // Revert, since this should never be accessible through a read
        source._ignorePropertyChange = true;
        source.SetValue(e.Property, e.OldValue);
    }

回答3:

It looks like you can use the CoerceValueCallback associated with the property via the FrameworkPropertyMetadata applied in the dependency property definition. Just install a callback that takes the second argument, the new value, passes it to the object via your own write-only mechanism, then returns null (or for value types, default(T)).

It's true that ".NET remembers the original value prior to coercion", but it won't be propagated via data-binding. Calls to GetValue will return the coerced value, which doesn't leak anything.

I'm using this to implement one-way convenience setters for the value of my primary property, which is a sequence of bytes. A user can bind a string, for example, to set the primary property to the encoded bytes (ASCII or UTF-8, depending what property is set). But not all byte sequences are valid UTF-8, so it isn't possible to reverse the conversion and read a string back through the convenience property.

public string AsciiData
{
    set { BinaryArray = Encoding.ASCII.GetBytes(value); }
}

public static readonly DependencyProperty AsciiDataProperty =
    DependencyProperty.Register("AsciiData",
        typeof(string),
        typeof(HexView),
        new FrameworkPropertyMetadata(null, CoerceAsciiData));

private static object CoerceAsciiData(DependencyObject target, object value)
{
    (target as HexView).AsciiData = value as string;
    return null;
}

The coercion handler can be removed via metadata replacement, so this isn't providing security, but it will prevent developers from accidentally creating coupling in wrong ways.