在 WPF 应用程序中声明转换器时,我应该:
- 在 App.xaml 中声明我的所有转换器(即在 中
<Application.Resources/>
),以便它可用于整个应用程序 - 在他们的部分中为每个
Page
///等声明只需要的转换Window
器ResourceDictionary
UserControl
Resources
- 完全不同的东西
关于可读性,方法 1 对我来说似乎是最好的,但我的问题是关于性能。就性能、内存等而言,哪种方法最节省资源?
在 WPF 应用程序中声明转换器时,我应该:
<Application.Resources/>
),以便它可用于整个应用程序Page
///等声明只需要的转换Window
器ResourceDictionary
UserControl
Resources
关于可读性,方法 1 对我来说似乎是最好的,但我的问题是关于性能。就性能、内存等而言,哪种方法最节省资源?
好吧,我根本不在 xaml 中声明它们。相反,我还从 MarkupExtension
. 像这样:
public class MyValueConverter : MarkupExtension, IValueConverter
{
private static MyValueConverter _converter = null;
public override object ProvideValue(IServiceProvider serviceProvider)
{
if (_converter == null) _converter = new MyValueConverter();
return _converter;
}
public object Convert
(object value, Type targetType, object parameter, CultureInfo culture) { }
public object ConvertBack
(object value, Type targetType, object parameter, CultureInfo culture) { }
}
这使我可以在任何地方使用我的转换器,如下所示:
Source="{Binding myValue, Converter={converters:MyValueConverter}}"
其中converters 是我在其中声明了我的转换器的命名空间。
仅从旧的 stackoverflow 线程中学到了这个技巧。
我有一个 ResourceDictionary ,它声明了几个常用的转换器,例如 bool-to-visibility 转换器。我直接在 App.xaml 中引用了这本字典。
我在页面/窗口级别(或在页面/窗口引用的 ResourceDictionary 中)声明了其他更特定于给定情况的转换器。
我无法明确回答性能问题,但如果它在加载时间或内存使用方面产生实际差异,我会感到非常惊讶。声明转换器基本上是一个对象实例化,因此它应该非常高效并且使用很少的内存,但我没有进行任何分析来比较应用程序级和窗口级的性能。
如果您只需要一个用于一个窗口的转换器,我会将它用于一个窗口(甚至只用于包含使用它的控件的容器控件)。
我认为这更易于维护-您可以查看转换器声明并能够分辨出它的用途。您知道,如果您更改该特定页面上的控件以不再使用转换器,您可以将其从页面资源中取出,而不会影响其他任何内容。相反,如果转换器是应用程序资源,那么确定正在使用它的对象就不是那么简单了(如果有的话)。
如果同一个转换器被多个页面使用,我仍然会将它放在每个页面资源下。实际上,它只是 XAML 中的一行。
无论如何,这是我的观点,截至今天。我期待另一篇文章提出完全相反的观点。:-)