相对于完整的.NET 4.5 框架来说，用于Windows Store 应用的.NET API 子集则显得如此之小。 具体而言， Reflection.Emit 变得不可用，且 System.Type 类中的大多数成员也都被迁移到了 System.Reflection.TypeInfo 类中。
.NET 团队把 System.Type 分解成了两个类—— System.Reflection.TypeInfo 和一个简化的 System.Type ——主要意在将类型定义与类型引用分离。早在处理程序集时，就已采用了这种划分方法。 Brandon Bray 在《 Evolving the .NET Reflection API 》一文中解释到：
System.Reflection.Assembly 类代表的是程序集定义，而 System.Reflection.AssemblyName 类代表的是程序集引用。前者提供了丰富的功能集合，而后者只是数据，它可以帮助你得到想要的定义。这正是我们想为 System.Type 采用的模型。
Type 仅提供了对某一类型的引用，并未加载类型本身的所有元数据。所有丰富的信息都在 TypeInfo 中——对于给定的 Type，你可以通过该类型的 TypeInfo 来访问它的元数据。这种方式的优点是，访问 Type 对象的时候并不需要加载必要的程序集——仅当访问 TypeInfo 类的时候才需要。这意味着，是否需要加载程序集可以由开发者根据需要来控制。
为了保持更好的工作集和响应能力，Reflection API 也开始用 IEnumerable 类型来替代常见的数组类型的返回值。
兼容性：新的 Reflection API 中的这种改变并非破坏性的——Windows Store 中的应用必须使用新模型，而对于以.NET 4.5 框架为目标的代码而言，早期的.NET 4.0 模型和新模型皆可使用。为了实现这一点，.NET 框架使用的类型层次结构稍微有点不同。假如你想在.NET 4.5 和 Windows Store 应用之间复用代码的话，微软建议你将其包装为一个可移植的类库。
查看英文原文： Reflection API Changes For Windows Store Apps
感谢贾国清对本文的审校。
给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ）或者腾讯微博（ @InfoQ ）关注我们，并与我们的编辑和其他读者朋友交流。
略懂技术的运营同学。
中国开发者画像洞察研究报告 2024
分析开发者的行为模式、工作价值、职业发展等内容，帮助整个行业生态更深入地理解开发者，为他们提供更精准...
评论