所谓数据绑定，其概念很简单，数据绑定决定了一个Source的改变会不会，以及怎样自动通知并改变Destination。Source可以是数据表，可以是XML，可以是一个内存数据，也可以是一个控件的某个属性值。Destination必须是一个Dependency Object的某个属性。这样的设定，使得数据的需求者（往往同时也是业务的处理者）和界面的提供者得以松绑。数据需求者仅需完成本身的业务逻辑，例如，被击中导致当前玩家掉血10点。至于这个减掉的10点如何在界面逻辑中表现，这个完全跟业务没关系，我一个业务的制作者没有知道它的必要。这样的松绑看似简单，但解决了一个潜在的问题：界面的开发往往比业务 Read More
http://blog.csdn.net/noslopforever/article/details/7413283这篇文章介绍了一下WPF的数据绑定，这是一种做法。回顾一下，数据绑定主要的几个组成部分：源数据池和源属性。目标数据池和目标属性。Binding：配置哪些源的改变，会使得哪些目标发生改变。前面也大概介绍了数据绑定基本需要解决的工作：源数据必须发布通知，这个通知应该由Binding来获取。Binding获取到通知后，根据配置，决定哪些目标属性将要发生更改，并修改目标属性。不同的实现，注意的主要问题，源数据和目标数据是一般没有什么问题的，最多就是Collection如何处理，这个没有任 Read More
最近想的越来越多。 十年前不会思考太多，功能完成了就感觉自己完成了自己的工作，后来发现完成是一回事儿，做得好就是另一回事，于是又朝着做得好努力，后来又发现做得好这个东西本身还挺复杂，怎么算好呢？强扩展性？简洁性？ 估计拿这个问题去问十个人，会有十一种以上的说法。 但私认为，这个答案应该是唯一的，四个字： 因地制宜。 我们可以用做得很牛逼很复杂的工厂模式去为未来生产不同的可扩展元素打下一个坚实的基础，但如果我们正在做的是一个寸土寸金，每一个字节内存和每一个指令都需要细斟细酌、且对扩展性几乎可以算无要求的驱动时，这么牛逼的工厂模式，则除了鸡肋以外还是鸡肋，一点意义都没有。 ... Read More