.NET 4.5 自定义反射上下文 : what is it useful for?

Question

What's New in the .NET Framework 4.5 Developer Preview提及

Ability to customize a reflection context to override default reflection behavior through the CustomReflectionContext class.

ReflectionContext的目的是什么？ ? MSDN 在这个问题上不是很清楚。

Answer 1

在过去的 .NET 中，在希望能够通过反射自动化某些功能和能够自定义它们之间一直存在紧张关系。例如，以 Visual Studio 中的“属性”面板为例 - 在显示某些 .NET 类型(例如，设计图面上的控件)的场景中，它可以自动发现并显示该类型定义的每个公共(public)属性。

对这种类型驱动的行为使用反射是很有用的，因为这意味着每个属性都会显示出来，而控件的开发人员不需要做任何事情。但它提出了一个问题:如果你想自定义东西怎么办，例如为特定属性定义分类或自定义编辑 UI？

.NET 中的经典解决方案是将一堆自定义属性添加到相关成员上。然而，一个问题是它可能意味着在运行时做有意义工作的代码部分最终取决于只在设计时做任何事情的类 - 依赖属性会阻止你分离运行时和设计时方面.您真的想将 VS 属性面板的自定义设计器 UI 的代码作为最终用户计算机上的控件库的一部分发布吗？

另一个问题是，在某些情况下，您可能希望动态决定您呈现的“属性”。最古老的例子之一(可追溯到 .NET 1.0)是放置 DataSet在某种网格控制(客户端或网络)中。对于强类型数据集，反射可能是网格发现源提供哪些属性的合适方式，但是 DataSet也可以动态使用，因此您需要一种方法让数据网格在运行时询问要显示哪些列。

(对此的一个答案是:正确设计你的 UI!像这样直接生成网格会导致糟糕的用户体验。然而，很多人都想以懒惰的方式来做，不管它是不是一个好主意......)

所以你会遇到这样的情况，有时你想要反射驱动的行为，但有时你想要能够在运行时完全控制。

为此出现了各种临时解决方案。你有整个TypeDescriptor和 PropertyDescriptor类型家族，它们在反射之上提供了一种可虚拟化的 View 。默认情况下，这只会从反射直接传递所有内容，但类型有机会在运行时选择提供自定义描述符，使它们能够修改甚至完全替换它们的外观。 ICustomTypeDescriptor是那个世界的一部分。

这为默认情况下需要反射驱动行为的问题提供了一种解决方案，如果需要，可以选择提供运行时驱动行为。但它不能解决您只想在设计时执行此操作的问题，并且您不想将该代码作为运行时可再发行组件的一部分发布。

所以几年前，Visual Studio 引入了它自己的特殊机制，用于在设计时增加类型信息。有许多约定驱动的行为，其中 Visual Studio 将自动发现与特定运行时组件相关的设计时组件，使您能够自定义设计体验，而无需将相关代码烘焙到可再发行组件中。 Blend 也使用了这种机制，尽管进行了一些调整，可以为 VS 和 Blend 提供不同的设计器作品。

当然，通过普通的反射 API 看不到这些 - VS 和 Blend 有一个位于反射之上的包装层来使这一切正常工作。

所以现在我们有两个虚拟化层可以传递到反射，或者可以增强反射产生的东西......

看起来在 .NET 4.5 中，CLR 团队决定，由于各个团队已经在做这种事情，而其他团队想要做更多的事情(MEF 团队对反射驱动和可选运行时有类似的要求- 增强行为)，这正是应该内置到运行时中的东西。

新模型似乎是这样的:ReflectionContext基类是一个抽象 API，通过它您可以获得反射 API 的虚拟化版本。它看似简单，因为其中一个主要思想是，如果您的唯一目标是在反射之​​上获得可虚拟化的包装器，则您不再需要像类型描述符系统这样的专门 API——反射现在是开箱即用的虚拟化。所以你可以写这种东西

public static void ShowAllAttributes(Type t)
{
    foreach (Attribute attr in t.GetCustomAttributes(true))
    {
        Console.WriteLine(attr);
    }
}

现在您总是能够编写它，但在 .NET 4.5 之前，这样的代码将始终针对“真实”类型信息工作，因为它使用反射。但多亏了反射上下文，现在可以通过虚拟化 Type 提供它。 .因此，请考虑这种非常无聊的类型:

class NoRealAttributes
{
}

如果你只是通过typeof(NoRealAttributes)到我的 ShowAllAttributes方法，它不会打印任何内容。但是我可以编写一个(有点人为的)自定义反射上下文:

class MyReflectionContext : CustomReflectionContext
{
    protected override IEnumerable<object> GetCustomAttributes(MemberInfo member, IEnumerable<object> declaredAttributes)
    {
        if (member == typeof(NoRealAttributes))
        {
            return new[] { new DefaultMemberAttribute("Foo") };
        }
        else
        {
            return base.GetCustomAttributes(member, declaredAttributes);
        }
    }
}

(顺便说一句，我认为 CustomReflectionContext 和它的基础 ReflectionContext 之间的区别在于后者定义了可虚拟化反射上下文的 API，而 CustomReflectionContext 添加了一些帮助程序，使您更容易实现这样的一个东西。)现在我可以用它来提供 Type 的虚拟化版本。对于我的类(class):

var ctx = new MyReflectionContext();
Type mapped = ctx.MapType(typeof(NoRealAttributes).GetTypeInfo());
ShowAllAttributes(mapped);

在此代码中，mapped仍指Type对象，所以知道如何使用反射 API 的任何东西都可以使用它，但它现在将报告实际不存在的属性的存在。当然，Type是抽象的，所以我们总是有一些从中派生出来的东西，如果你调用 mapped.GetType()你会看到它实际上是一个 System.Reflection.Context.Custom.CustomType而不是 System.RuntimeType你通常会看到。还有那个CustomType对象属于我的自定义上下文，因此您通过它获得的任何其他反射 API 对象(例如，如果您编写了 mapped.Assembly.GetTypes() )，您还将获得通过我的自定义上下文的自定义对象，这将有机会修改任何其他出来的东西。

所以代码可以使用定制的 Type 在类型系统中导航。目的。尽管这些代码使用的是普通的基本反射 API，但我现在有机会自定义任何我认为合适的内容。

如果您要求，您只能获得此虚拟化 View 。例如，.NET 4.5 中的 MEF 查找自定义属性，指定它应该使用用户提供的自定义反射上下文，否则将回退到普通反射。 (在我的 ShowAllAttributes 方法的情况下，它使用我选择传入的任何 Type 对象 - 它不知道它是否正在获取虚拟化或“真实”类型的对象。)

简而言之，这意味着如果您想要虚拟化类型信息，您不再需要围绕反射 API 的临时包装器。