【IT168 专稿】 如果经历过.NET的1.0,1.1以及2.0版本，你就很可能发现.NET 3.0中的WPF区域中的一些文档有点不同。具体来说，WPF负责介绍几个CLR和托管代码封装方面的新概念。WPF SDK团队为在参考资料中展示这些新概念而做的努力是很大的进步，主要致力于改变，因为其它的技术也在它们的API中采用了相同或者类似的范例。

System.Reflection和.NET 3.0 SDK 

   微软用于创建托管SDK框架的“魔法”其实就是映射进程（典型的就是采用托管映射，但有时也有非托管的映射，这取决于API）。编译工具映射所有.NET 3.0的API，SDK作者就在纲要中填充映射告诉我们的关于API的消息（至少这是一个目标）。但是对于比System.Reflection本身更新的编程概念的映射，System.Reflection做得不是特别好。你可以通过查看定制特性来得到一些更具体的信息。但对于那些像XAML一样的语言，或者独立属性，由于System.Reflectio从1.1开始就没有本质的改变，所以不能为3.0提供好的API。如果你要编写自己的映射，你不得不做些额外的创造工作（我不会在这里描述这个问题，因为太复杂了，而且超出了本主题的范围）。对我们的SDK开发团队来说，他们也不得不非常熟悉映射代码。然后，其他的各种各样的人，包括一些像我们这样的程序员不得不跟上表示策略——怎么在更好，更标准的托管代码段文档中表示额外的信息，比如异常和返回值等。
                    
    正在讨论的隐藏的秘密是参考主题部分，这部分是大量的设计会议和开发工作的结果。每一个隐藏秘密都代表着编程的一个具体方面，和WPF非常相关并且对WPF来说是新内容。所有的信息都在SDK页面，等待你的发掘。但是，我们还没搞清楚这些突然在WPF参考文档中出现的额外段落是什么，以及他们意味着什么。
  
   抛开这些吧。让我们来照亮这些WPF文档中隐藏的秘密。一切都会得到解释！

独立属性

    很多时候会被问道一个问题“独立属性到底是什么？”或者一个相关的更尖锐的问题“我为什么要去关心一个东西是不是独立属性呢？”我们的答案是：独立属性总览。

    跨过这个概念上的障碍之后，下一个逻辑上的问题可能是“好吧，独立属性就是一种支持CLR属性的方式，那我该怎么分别那些属性是通过这种方式被支持的呢？”我们遇到的第一个隐藏秘密是：独立属性，和独立属性信息段。
   
    在文档中提到两种方法来判断某个给定的属性是否是独立属性：
1）当你在浏览任何类型的成员表，并且看到公共属性，读描述的时候。如果这个属性是独立属性，那么描述的最后一句就是“这是一个独立特性。”
2）假设你在说明CLR属性的SDK的主题页面。同样，在成员表的相同的描述中，你可以找到这句话“这是一个独立属性”。除了描述外，每一个独立属性的属性页面内还有一段可以被合适地成为独立属性信息段。这一段在表格中包含两点：

    一个到含有独立属性标志符的域的链接。很多属性系统API函数都需要这个标志符以执行一个属性或者获得关于它的信息。有人说，对那些只是获取或设置某个已经存在的具体属性的应用程序编程来说，使用属性系统API并不总是必须的，因为你可以调用更简单的独立属性CLR“封装”。这样，标志符主要是和包含独立属性的高级编程任务相关，比如处理属性元数据，或者追踪属性值。

   如果一个属性是框架层的属性，那么独立属性信息段会把元数据中“标记”为true的列出来。当独立属性被WPF框架层解释时，标记报告独立属性的某些共同特征，尤其是子特征，比如，整体系统，数据绑定，或属性值继承。SDK报告这些标记，因为这有助于实例了解改变属性是否会强迫修改整体设计，或是否你可以省略指定绑定的两个状态，因为这是独立属性的默认设置。
默认值

    横跨独立属性和“常规”属性的一个概念是默认值。一般来说，.NET文档会在属性值段告诉你属性的默认值，并且为保持一致性，这也是默认属性被报告给独立属性的地方。但是，独立属性默认值实际上来自属性元数据，尽管在一个平面上CLR属性可能来自一个类或者是拓展执行。这样，通过重写属性元数据，独立属性就可以被子类或新的属性拥有者轻易改变。在已有的WPF独立属性中偶尔会发生这种情况。当发生时，每一个类的重写都会被记录在Remark段。