把问题抛给用户之徒增复杂度的SilverLight依赖属性与附加属性
对于SilverLight为什么引入依赖属性与附加属性，官方的说法是减少内存消耗，提高性能。而在我看来这只是掩盖自己懒惰或无能的一个借口。首先我们看一下微软面对的问题，就WPF来说，内存消耗不能太大，性能也不能比Winform还低，就Silverlight来说，受限于网络带宽，还有运行时控件不能太大，XAP文件也不能太大这些限制。这些问题都是微软应该在框架内部解决的问题，你不能把责任甩给用户-开发人员，依赖属性与附加属性就是微软甩给我们的猴子。
  Lamda表达式都能让编译器搞定，区区一个依赖属性和附加属性，增加一个Attribute，让编译器去干岂不是更好？更进一步，检查所有代码对这个属性的使用情况，自动决定编译成依赖属性还是普通属性就更好了，再最后，通过编译器的优化参数一步到位，干脆这两个概念在.net开发中就没存在的必要。
  WPF和Silverlight的性能最后是通过使用DirectX和硬件加速解决的，内存消耗大的问题至今仍存，估计是在内存动辄几个G的情况下，微软把解决内存问题的优先级放在了性能之后。但由此也可看到所谓依赖属性与附加属性既没解决性能问题也没解决内存问题，终归是个治标不治本的东西。
  我怀疑是不是SIlverlight和WPF开发组没争取到.Net核心组老大的支持，自己又没法修改编译器、运行时这些核心的东西，最后没办法才搞出了这个依赖属性折中方案。到现在呢，船大难掉头，只好走下去了。哈哈

------解决方案--------------------
并不排除你常用的属性定义法。

其实早在winform就有离散的属性定义了。比如有些控件的class并没有某个属性，只是事后的dll中才扩展的，可是vs的属性编辑器就可以识别出来，并且自动帮用户在ide上编辑、设置和保存。只不过在winform中，扩展属性不是一个大量使用的功能，是微软研究了20年才放入标准ide里边的。但是这已经显得很强大了。

silverlight则大量地使用离散属性定义，虽然诡异但是灵活。比如你把一个控件放入Grid内部，你就可以在ide的帮助下直接编辑其Grid.Row属性。可是这个控件的class源代码中并没有这个属性，其实只是为这个控件增加了一个key=Grid.RowProperty的属性。

打个比方吧，我们定一个“顾客”这个实体。可是之后使用这个系统的开发人员发现需要为某些顾客增加“爱老婆还是爱情人”这个新属性，程序员不需要去重新修改顾客实体的class源代码，直接为顾客增加一个离散的叫做这个名字的属性（这个属性名字在一个叫做“第三者插足”class中定义为DependencyProperty）并且赋值为true就行了。

对象的属性值与对象分开管理，是为了实现一种过去从来没有过的“灵活性”，而不是为了单纯地节省资源。实际上，节省了一点内存，可是大大增加了程序管理开销。有关对象的知识全都是离散的而不是与主体组合的，它增加了软件的灵活性，这才是主要的。