WPF/Silverlight的数据绑定设计的真糟糕

简介:

WPF/Silverlight的数据绑定体系设计的真糟糕,几乎每用一次就要在心中骂一次,不知道是哪个家伙设计的,就像Asp.Net中的ViewState一样,拙劣得很:

(1)很难用,一些常见的简单场合使用起来很麻烦;

(2)想整个搞清楚很杀脑细胞,不是循序渐进的过程;

(3)不整个搞清楚就用不好,或者用的很别扭。

总之,就是一个这样的怪胎——简单的场景下使用很麻烦(增加了很多工作量),复杂的场景下使用很绕弯(也减少了不少工作量)。抄起原子弹当锤子用。一般的开发,哪有那么多复杂的场景?大部分情况都是简单的场景。我们需要的是一个在简单的场景下使用简单,在复杂的场景下使用略微复杂的设计,就像《.Net设计规范》中标榜的那样应该是一个倾斜的山坡(下图左),而不是像屋檐(下图右)。

image

下面开骂,参考对象是Flex哥哥:

(1)最常用的场景是把A或者A的属性F绑定到B的属性Source上;

WPF/SL下:

Source="{Binding ElementName=A, Path=F}"

Flex下:

Source="{A.F}"

这是最最常用的场景,WPF/SL罗哩罗嗦不说,还是弱类型性质的绑定,很容易写错,写错了编译器也不报错。

(2)再一个常见的场景是进行简单的判断或者简单的类型转换,这种应用非常常见。

WPF/SL下:

要用IValueConverter,blablabla … 要写一大堆代码。我还没写过IValueConverter,前面的场景还可以忍受,这种情况就忍无可忍了,直接放弃使用绑定了。下面是从网上找的例子:

[ValueConversion(typeof(DateTime), typeof(String))] 
public class DateConverter : IValueConverter 

    public object Convert(object value, Type targetType, object parameter, CultureInfo culture) 
    { 
        DateTime date = (DateTime)value; 
        return "now is "+date.ToString(); 
    }

    public object ConvertBack(object value, Type targetType, object parameter, CultureInfo culture) 
    { 
        string strValue = value.ToString(); 
        DateTime resultDateTime; 
        if (DateTime.TryParse(strValue, out resultDateTime)) 
        { 
            return resultDateTime; 
        } 
        return value; 
    } 
}

这不是给自己找虐吗?

Flex下:

function convert(obj:Object):String

{

   …

}

Source="{convert(A.F)}"

也可以直接在大括号里面写语句,如:

toValue="{controlsBar.y - 45}"

下面看一段Flex代码:

<mx:AnimateProperty target="{controlsBar}" 
                    property="y" fromValue="{controlsBar.y}" 
                    toValue="{controlsBar.y - 45}"> 
</mx:AnimateProperty>

这代码要用WPF/SL写,不知道会多别扭。.Net空有lambda表达式,又不能用于数据绑定的内部,真是悲哀(可以绕道用,但十分别扭)。

(3)再一个常见的场景就是自定义绑定源

WPF/SL下,还是网上找的代码:

public class MenuButtonModel : INotifyPropertyChanged 

    public event PropertyChangedEventHandler PropertyChanged; 
    public void NotifyPropertyChanged(string propertyName) 
    { 
        if (PropertyChanged != null) 
        { 
            PropertyChanged(this, new PropertyChangedEventArgs(propertyName)); 
        } 
    }

    private bool? _hasFocus; 
    public bool? HasFocus 
    { 
        get { return _hasFocus; } 
        set 
        { 
            _hasFocus = value; 
            NotifyPropertyChanged("HasFocus"); 
        } 
    }

    private string _iconPath; 
    public string IconPath 
    { 
        get { return _iconPath; } 
        set 
        { 
            _iconPath = value; 
            NotifyPropertyChanged("IconPath"); 
        } 
    } 
}


对应Flex的实现:

[Bindable] 
public class MenuButtonModel : IEventDispatcher 

    public var hasFocus:Boolean; 
    public var iconPath:String; 
}


加一个Bindable就把里面的字段啊,属性啊,全设为改变后发出一个事件。如果只想对特定字段或属性进行绑定,则是:

public class MenuButtonModel : IEventDispatcher 

    [Bindable] 
    public var hasFocus:Boolean; 
    ...

    [Bindable] 
    public function set iconPath():String 
    { 
        ... 
    } 
}

相比较而言,Flex的语法简介太多了。.Net空有“特性”这玩意,在睡大觉。

以上三种是最最常见的绑定场景,WPF/SL那语法就是找虐用的。相比较WPF/SL,Flex的绑定语法使用简单,又是强类型,学习3分钟就可以上手开发了。手中只有一本WPF的书《WPF核心技术》,整整用了一章讲数据绑定(第6章),连XPath绑定也单独作为一个小节来讲,晕。如果WPF/SL实现了Flex的绑定语法,只需要提供一个扩展方法就搞定了的事情,搞得这么麻烦。

当然,WPF/SL的绑定机制也有优秀的一面,就是当应用场景比较复杂时,会比Flex的数据绑定要简单一点。比如说双向绑定(这玩意用的很少吧),双向绑定在Flex下其实也不麻烦,不需要学新东西即可实现:

x={B.y}

y={A.x}

绑定两次即可,关键是语法比较简单,写起来并不费事,且绑定逻辑一目了然。WPF/SL写起来虽然简单一点,但有副作用。不知道啥时候就被别人给代表了,而不是自己主动去声明让别人来代表自己。

再比如说,上面的第三种绑定场景,Flex下只能发出PropertyChanged事件,WPF/SL下可以自定义事件类型,触发时也可以选择触发,这种情况,Flex下就要依靠OO技法来实现了。至于Tree绑定,DataGrid的绑定,WPF/SL和Flex是半斤八两。还有些更复杂的场景,没遇见过,就不做评价了。

====

这玩意不知道是哪个鼠标流大哥设计的,过渡设计的经典案例,真应该拉出去tjjtds。写代码写得实在不爽,本来C#是很优雅的东西,WPF也是很优秀的产品,一用到数据绑定就像踩着大便一样……忍不住撰文骂之。

本文转自xiaotie博客园博客,原文链接http://www.cnblogs.com/xiaotie/archive/2011/02/14/1953993.html如需转载请自行联系原作者


xiaotie 集异璧实验室(GEBLAB)

目录
打赏
0
1
1
1
23
分享
相关文章
解决办法:dpkg: 错误: 无法打开软件包的 info 文件 /var/lib/dpkg/available 以便读取: 没有那个文件或目录
解决办法:dpkg: 错误: 无法打开软件包的 info 文件 /var/lib/dpkg/available 以便读取: 没有那个文件或目录
658 0
技术探索的心得与感悟
在这篇文章中,我们将深入探讨技术探索过程中的心得与感悟。通过分析个人经历、项目实践和技术发展的趋势,总结出有益的经验和启示,以期为读者提供一些参考和借鉴。本文将涵盖从基础学习到高级应用的多个方面,分享一些实用的技巧和方法,帮助你更好地理解和应用技术,实现个人成长和发展。
智能时代的伦理困境:人工智能决策的透明度与责任归属
当AI技术逐渐渗透到我们生活的每一个角落,它带来的便利和效率提升是显而易见的。然而,随之而来的伦理挑战也不容忽视。本文将探讨AI在做出决策时面临的透明度问题,以及由此引发的责任归属难题。通过分析AI系统的工作原理、决策过程及其对个人和社会可能产生的影响,我们将提出一系列针对当前AI伦理困境的解决方案和建议,旨在促进AI技术的健康发展同时保护人类社会的基本伦理原则。
1089 11
Pluck-CMS-Pluck-4.7.16 远程代码执行(CVE-2022-26965)
Pluck-CMS-Pluck-4.7.16 远程代码执行(CVE-2022-26965)
状态机(State Machines):理解、设计和应用有限状态机
状态机(State Machines)是一种强大的计算模型和设计工具,用于建模和控制有限状态的系统和行为。无论是在软件开发、自动化控制、游戏设计还是其他领域,状态机都发挥着关键作用。本博客将深入探讨状态机的概念、工作原理以及如何在不同应用中设计和应用它们。
7724 0
ModuleNotFoundError: No module named 'torchstat'
ModuleNotFoundError: No module named 'torchstat'
619 0
ModuleNotFoundError: No module named 'torchstat'
《Java单元测试实战》——基础知识:Java单元测试技巧之PowerMock(2)
《Java单元测试实战》——基础知识:Java单元测试技巧之PowerMock(2)
329 0
AI助理

你好,我是AI助理

可以解答问题、推荐解决方案等

登录插画

登录以查看您的控制台资源

管理云资源
状态一览
快捷访问