1,Data Binding在WPF中的地位程序员
程序的本质是数据+算法。数据会在存储、逻辑和界面三层之间流通,因此站在数据的角度上来看,这三层都很重要。但算法在3层中的分布是不均匀的,对于一个3层结构的程序来讲,算法通常分布在这几处:算法
A。数据库内部。数据库
B。读取和写回数据。工具
C。业务逻辑。单元测试
D。数据展现。测试
E。界面与逻辑的交互。优化
A,B两部分的算法通常都很是稳定,不会轻易去改动,复用性也很高;C处与客户需求最紧密,最复杂,变化最大,大多少算法都集中在这里。D,E负责UI和逻辑的交互,也占有必定量的算法。动画
显然,C部分是程序的核心,是开发的重中之重,因此咱们应该把精力集中在C部分。然而,D,E两部分却常常成为麻烦的来源。首先这两部分都与逻辑紧密相关,一不当心就有可能把原本该放在逻辑层里面的算法写进这两部分(因此才有了MVC、MVP等模式来避免这种状况出现)。其次,这两部分以消息或者事件的方式与逻辑层沟通,一旦出现同一个数据须要在多出展现/修改时,用于同步的代码错综复杂;最后,D和E原本是互逆的一对儿。但却须要分开来写-----显示数据写一个算法,修改数据再写一个算法。总之致使的结果就是D和E两部分会占去一部分算法,搞很差还会牵扯很多精力。.net
问题的根源在于逻辑层和展现层的地位不固定------当实现客户需求的时候,逻辑层的确处于核心地位。但到了实现UI的时候,展现层又处于核心的地位。WPF做为一种专业的展现层技术,华丽的外观和动画只是它的表层现象,最重要的是他在深层次上把程序员的思惟固定在了逻辑层,让展现层永远处于逻辑层的从属地位。WPF具备这种能力的关键在于它引入了Data Binding概念及与之配套的Dependency Property系统和DataTemplate。orm
从传统的Winform转移到WPF上,对于一个三层程序而言,数据存储层由数据库和文件系统组成,数据传输和处理仍然使用.NetFramework的ADO.NET等基本类(与Winform开发同样)。展现层则使用WPF类库来实现,而展现层和逻辑层的沟通就使用Data Binding来实现。可见,Data Binding在WPF中所起的做用就是高速公路的做用。有了这条高速公路,加工好的数据自动送达用户界面并加以显示,被用户修改过的数据也会自动传回业务逻辑层,一旦数据被加工好又会被送往界面。。。。程序的逻辑层就像是一个强有力的引擎一直在运做,用加工好的数据驱动用户界面也文字、图形、动画等形式把数据显示出来------这就是数据驱动UI。
引入Data Binding以后,D,E两部分被简化了不少。首先,数据在逻辑层和用户界面直来之去、不涉及逻辑问题,这样的用户界面部分基本上不包含算法:Data Binding自己就是双向通讯,因此至关于把D和E合二为一;对于多个UI元素关注同一个数据的状况,只须要用Data Binding将这些UI元素和数据一一关联上(以数据为中心的星形结构),当数据变化后,这些UI元素会同步显示这一变化。前面提到的问题也都迎刃而解了。更重要的是通过这样的优化,全部与业务逻辑相关的算法都处在业务逻辑层,逻辑层成了一个能够独立运转,完整的体系,而用户界面则不须要任何逻辑代码。彻底依赖和从属于业务逻辑层。这样作有两个显而易见的好处,第一:若是把UI看作是应用程序的皮,把存储层和逻辑层看做是程序的瓤,咱们能够很轻易的把皮撕下来换一个新的。第二:由于数据层可以独立运做,自成体系,因此咱们能够进行更完善的单元测试而无需借助UI自动化测试工具----你彻底能够把单元测试看做是一个“看不见的UI”,单元测试只是使用这个UI绕过真实的UI直接测试业务逻辑罢了。