typedelegator 是 .net 中用于创建可自定义 type 视图的代理类，它通过继承 typedelegator 并重写其 virtual 方法来改变反射行为，而无需修改原始类型；由于 system.type 是 sealed 类，无法直接继承，因此 typedelegator 提供了官方推荐的扩展方式，允许在反射层面拦截和修改类型信息，如修改类型名称或过滤方法；其典型应用场景包括动态代理、aop、orm 延迟加载、元数据注入及序列化框架等高级场景；使用时需继承 typedelegator，在构造函数中传入被包装类型，并重写如 name、getmethods 等方法以定制行为，但需注意它仅改变反射视图，不改变实际对象类型，通过 activator.createinstance 创建的实例仍为原始类型；因此 typedelegator 主要用于操控反射查询结果，为动态生成类型提供统一的 type 接口，常配合 reflection.emit 等技术实现完整代理功能。
.NET中的
TypeDelegator类，本质上是一个类型包装器或者说代理。它的核心作用是让你能够基于一个已存在的
Type对象，创建一个新的、行为上可以被定制或修改的
Type视图，而无需直接继承或改变原始类型。这在很多场景下非常有用，比如当你需要动态地修改一个类型的反射行为，或者为现有类型添加一些“虚拟”的成员，而又不能直接修改其定义时。
解决方案
TypeDelegator的设计哲学就是“委托”。它继承自抽象基类
Type，但其内部持有一个实际的
Type实例（我们称之为被包装的类型）。
TypeDelegator的绝大多数成员方法（如
GetMethods、
GetProperties、
Name等）都被重写了，它们默认的行为就是简单地调用其内部被包装类型对应的成员。
这意味着，如果你只是实例化一个
TypeDelegator并传入一个
Type，它的行为和原始
Type几乎一模一样。但关键在于，
TypeDelegator的这些成员方法都是
virtual的，这为我们提供了重写的机会。通过继承
TypeDelegator并重写特定的方法，我们就可以在反射系统查询类型信息时，拦截并修改这些查询的结果。
举个例子，你可以重写
GetMethods()方法，在返回原始类型的方法列表之前，动态地添加一个“不存在”的方法信息，或者过滤掉一些你不想暴露的方法。这就像给一个类型戴上了一副“墨镜”，让外部世界看到的是一个经过你定制的、略有不同的它。
为什么我不能直接继承System.Type
？
这是个很好的问题，也是
TypeDelegator存在的根本原因之一。如果你尝试去继承
System.Type，你会发现编译器会报错，因为它是一个
sealed（密封）类。也就是说，微软的设计者们明确禁止了直接从
Type类派生新的类型。
我个人猜测，这背后可能有几层考虑：首先，
System.Type是.NET类型系统的核心基石，它的行为需要高度一致性和可预测性。如果允许任意继承，可能会导致各种复杂的、不可预期的行为模式，从而破坏反射机制的健壮性。其次，
Type的内部实现可能与CLR（Common Language Runtime）的底层运行时紧密耦合，直接继承并修改其行为可能会带来安全或性能上的风险。
因此，当我们需要一个“看起来像某个类型，但又有点不一样”的类型描述时，
TypeDelegator就成了唯一的、官方推荐的途径。它提供了一个受控的扩展点，而不是一个完全开放的继承模型。这有点像在说：“你可以定制这个类型在反射层面的表现，但你不能改变它作为CLR类型本身的本质。”
技术上面应用了三层结构，AJAX框架，URL重写等基础的开发。并用了动软的代码生成器及数据访问类，加进了一些自己用到的小功能，算是整理了一些自己的操作类。系统设计上面说不出用什么模式，大体设计是后台分两级分类，设置好一级之后，再设置二级并选择栏目类型，如内容，列表，上传文件，新窗口等。这样就可以生成无限多个二级分类，也就是网站栏目。对于扩展性来说，如果有新的需求可以直接加一个栏目类型并新加功能操作
TypeDelegator
在实际中有什么用武之地？
说实话，
TypeDelegator不是我们日常写业务代码会频繁接触的类，它更多地出现在一些高级框架或库的内部实现中。
一个非常典型的应用场景是动态代理（Dynamic Proxy）和AOP（Aspect-Oriented Programming）框架。比如，一些ORM（Object-Relational Mapping）框架为了实现延迟加载（Lazy Loading），可能会为实体类生成代理。这些代理类在运行时被创建，它们需要“看起来”和原始实体类一样，但它们的某些属性或方法访问会被拦截，以便在需要时才从数据库加载数据。
TypeDelegator可以用来构建一个表示这种代理类型的
Type对象，它能模拟原始类型的结构，同时注入拦截逻辑。
再比如，元数据注入或修改。假设你有一个第三方库，它通过反射来读取类的特定属性或方法，但你又无法修改这个第三方库的代码，也无法直接修改你自己的类定义（比如它来自一个编译好的程序集）。这时，你可以用
TypeDelegator创建一个“包装类型”，在这个包装类型中，你可以动态地添加、移除或修改一些“虚拟”的自定义属性，或者改变方法的签名，从而欺骗那个第三方库，让它按照你的意图工作。这在某些复杂的插件系统或代码生成场景中，可能会派上用场。
它还可能被用于序列化/反序列化框架，当框架需要以一种非标准的方式来处理某些类型时，比如在序列化时隐藏某些属性，或者在反序列化时注入一些额外的逻辑，而又不想通过修改原始类型或使用复杂的特性来实现时。
如何使用TypeDelegator
包装一个类型？
使用
TypeDelegator的基本步骤是：继承它，并在构造函数中传入你想要包装的基类型。然后，重写你想要修改行为的
Type成员。
下面是一个简单的示例，展示如何创建一个
TypeDelegator的子类，它会改变被包装类型的
Name，并过滤掉所有以
_Internal结尾的方法：
using System;
using System.Reflection;
public class MyCustomTypeDelegator : TypeDelegator
{
private readonly string _customName;
// 构造函数：传入要包装的类型和自定义的名称
public MyCustomTypeDelegator(Type delegatingType, string customName)
: base(delegatingType)
{
_customName = customName;
}
// 重写 Name 属性，返回自定义的名称
public override string Name
{
get { return _customName; }
}
// 重写 GetMethods 方法，过滤掉特定命名模式的方法
public override MethodInfo[] GetMethods(BindingFlags bindingAttr)
{
// 先获取原始类型的所有方法
MethodInfo[] originalMethods = base.GetMethods(bindingAttr);
// 过滤掉名称以 "_Internal" 结尾的方法
var filteredMethods = new System.Collections.Generic.List();
foreach (var method in originalMethods)
{
if (!method.Name.EndsWith("_Internal"))
{
filteredMethods.Add(method);
}
}
return filteredMethods.ToArray();
}
// 你也可以重写其他成员，比如 GetProperties, GetFields, GetCustomAttributes 等
// 比如，让 GetProperties 总是返回空数组，表示该类型没有公共属性
// public override PropertyInfo[] GetProperties(BindingFlags bindingAttr)
// {
// return new PropertyInfo[0];
// }
}
// 示例用法
public class OriginalClass
{
public string PublicProperty { get; set; }
public void DoSomething() { Console.WriteLine("Doing something."); }
public void DoSomething_Internal() { Console.WriteLine("This should be hidden."); }
public static void StaticMethod() { Console.WriteLine("Static method."); }
}
public class Program
{
public static void Main(string[] args)
{
Type originalType = typeof(OriginalClass);
Console.WriteLine($"Original Type Name: {originalType.Name}"); // Output: OriginalClass
// 使用自定义的 TypeDelegator 包装 OriginalClass
Type wrappedType = new MyCustomTypeDelegator(originalType, "RenamedClass");
Console.WriteLine($"Wrapped Type Name: {wrappedType.Name}"); // Output: RenamedClass
Console.WriteLine("\n--- Original Methods ---");
foreach (var method in originalType.GetMethods(BindingFlags.Public | BindingFlags.Instance | BindingFlags.Static))
{
Console.WriteLine($"- {method.Name}");
}
/* Output:
- DoSomething
- DoSomething_Internal
- StaticMethod
- get_PublicProperty
- set_PublicProperty
- ToString
- Equals
- GetHashCode
- GetType
*/
Console.WriteLine("\n--- Wrapped Methods ---");
foreach (var method in wrappedType.GetMethods(BindingFlags.Public | BindingFlags.Instance | BindingFlags.Static))
{
Console.WriteLine($"- {method.Name}");
}
/* Output:
- DoSomething
- StaticMethod
- get_PublicProperty
- set_PublicProperty
- ToString
- Equals
- GetHashCode
- GetType
(DoSomething_Internal 被过滤掉了)
*/
// 尝试通过包装类型创建实例（注意：TypeDelegator本身不改变实际类型创建行为）
// 如果你需要改变实例创建行为，那通常需要配合 Reflection.Emit 或其他代理生成技术
try
{
var instance = Activator.CreateInstance(wrappedType);
Console.WriteLine($"\nCreated instance of type: {instance.GetType().Name}"); // 仍然是 OriginalClass
// 实际上，这里的 instance 仍然是 OriginalClass 的实例，
// TypeDelegator 只是改变了反射层面上的“视图”，而不是对象的实际类型。
// 如果要生成行为不同的代理对象，需要更复杂的动态代码生成。
}
catch (Exception ex)
{
Console.WriteLine($"Error creating instance: {ex.Message}");
}
}
} 这段代码展示了
TypeDelegator如何改变一个类型在反射层面的表现。需要注意的是，
TypeDelegator本身并不会改变你通过
Activator.CreateInstance(wrappedType)创建出来的对象的实际类型。它依然会创建原始类型的实例。
TypeDelegator的作用主要体现在反射查询上，它改变的是反射API（如
GetType()、
GetMethods()等）返回给你的信息。如果你需要生成一个行为上真正不同的代理对象，那通常需要结合
System.Reflection.Emit或其他动态代码生成库来实现。
TypeDelegator更像是为这些更复杂的动态生成提供了一个统一的
Type接口，让你能以标准的方式来描述这些动态生成的类型。
