WPF：在绑定时指定 ValueConverter 的另一种方法答案

【问题标题】：WPF : An alternative way to specify a ValueConverter on bindingWPF：在绑定时指定 ValueConverter 的另一种方法
【发布时间】：2009-06-03 20:41:33
【问题描述】：

我遇到的为绑定指定值转换器的最常见方法是：
1. 将值转换器的实例创建为具有键的资源。
2.使用StaticResource标记扩展引用实例：

<TextBlock Text="{Binding Converter={StaticResource myFormatter}" />

问：使用静态实例有什么问题如下：

<TextBlock Text="{Binding Path=Description, Converter={x:Static local:MyFormatter.Instance}}"/>

// where Instance is declared as:
public readonly static MyFormatter Instance = new MyFormatter();

在我的例子中，值转换器是不可变的。

编辑：另一种方式是to turn the converter into an extension 以便您使用标记扩展格式指定转换器：

<TextBlock Text="{Binding Converter={local:MyFormatter}}"/>

【问题讨论】：

注意：当你把converter变成扩展时，每次访问都会创建对象。

标签： wpf binding valueconverter

【解决方案1】：

技术上没问题，但实际上我不喜欢它：

如果您将转换器声明为资源，则您有一个单一的参考点。如果您更改转换器的命名空间或类名，那么您只有一个地方可以更新。
如果将其声明为静态，则需要将clr-namespace 放在每个使用转换器的 xaml 文件的顶部。如果您将其声明为资源，则不会。
{Binding Converter={StaticResource myFormatter} 比静态的更短且更易于阅读。从长远来看，这将比您想象的更能帮助您。

【讨论】：

假设我只使用了一次转换器（我确实这样做了），在这种情况下，声明资源 + 引用资源将需要更多的输入。但你说得有道理。 +1
当然可以，但是您可能会拥有多个 valueConverter，并且其中一些其他 valueConverter 将被重新使用（因此您希望它们作为资源）...所以您可能应该把这个和所有其他的放在一起，这样它就保持一致:-)

【解决方案2】：

只要格式化程序真的没有状态，这应该没问题。但它并不等同。在第一种情况下，每个基于 XAML 的控件实例都有一个类的实例。在第二种情况下，只会创建一个实例。

【讨论】：

对了，另外一个区别就是类实例化时会调用静态构造函数（即初始化静态实例），而资源定义转换器发生在WPF组件构造时（粗略地说）。
这引发了人们会编写带有状态的转换器的可怕前景——我不想像那样调试代码！咖啡前，我想不出理由。