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两部分会占去一部分算法，搞欠好还会牵扯不少精力。
问题的泉源在于逻辑层和展示层的职位地方不固定------当实现客户需求的时候，逻辑层简直处于核心职位地方。但到了实现UI的时候，展示层又处于核心的职位地方。WPF作为一种专业的展示层技术，富丽的外不雅观和动画只是它的表层现象，最重要的是他在深条理上把措施员的思维固定在了逻辑层，让展示层永远处于逻辑层的隶属职位地方。WPF具有这种能力的关键在于它引入了Data Binding观点及与之配套的Dependency Property系统和DataTemplate。
从传统的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直接测试业务逻辑罢了。