lam*_*ora 0 .net wpf performance properties converter
在WPF中,最好创建一个属性"complex"(即"Visibility"类型)或一个简单属性(即boolean类型),然后使用转换器绑定属性？第一种方式是写短,但我不知道什么是更好的表现.
使用转换器的性能损失可以忽略不计.但是,您应该选择的是您实施该物业的地方.
甲Visibility属性仅使得在UI层(自定义控制或者一个视图模型)的一类感.如果您正在模型类上创建一个恰好在此实例中驱动UI 的属性,那么使用布尔值和转换器会更有意义.
编辑:添加(轻微做作)的例子
例如,假设你有一个叫做可编辑的对象数据类(模型)Foo,并且Foo可以是"简单"或"高级"."高级" Foo将在UI中显示额外的编辑控件 - 因此我们需要将Visibility高级编辑面板的属性绑定到某个属性.
您的Foo班级可以拥有一个属性来表明它是否已提升.该属性绝对应该是一个布尔值 - 不是Visibility- 因为你的Foo类不应该关心显示它的UI的任何细节.所以布尔值Foo.IsAdvanced将是一个合适的属性.
在这种情况下,您可以直接绑定Foo.IsAdvanced并使用转换器.你肯定不希望做的就是创建一个Visibility属性Foo.AdvancedEditControlVisibility,因为Foo被认为是后端数据类.
如果要创建不需要转换器的属性,则应在更高级别创建该属性,该类属于UI.一些架构模式将其称为"ViewModel"类 - 它是一个以更适合UI显示的方式呈现模型的类.因此,您可以创建一个类,该类接受Foo并公开基于其值的AdvancedEditControlVisibility属性.Foo.IsAdvanced
在这种情况下,您可以直接绑定到viewmodel上的属性而不使用转换器.请注意,最终你已经完成了转换 - 你只是将它作为代码的一个更明确的部分,而不是局限于标记.
这里的思考过程是viewmodel是一个"更高级别"的类 - 包含数据类并包含特定于UI的逻辑的类 - 因此包含特定于UI的代码更合适.理想情况下,您应该依次获取项目的每个类,并确保它具有特定目的:如果Foo是一个包含数据的业务对象,为什么它应该公开(甚至关心!)某些UI的可见性用来显示它？如果您Foo在命令行应用程序或Web应用程序中放置会发生什么？如果您在业务类中具有特定于WPF-UI的逻辑,那么您的封装是错误的 - 但以这种方式分离关注点有时是最困难的事情之一.
而且在性能方面你会发现一点点不同.:-)