为什么在 .NET 框架的某些类中选择 System.Type arguments 而不是 generics？

Question

我注意到 .NET 框架中的几个内置类/方法采用 System.Type 参数，其中（在我看来）使用 generics 会更干净。 例如，要创建一个 DataContractSerializer 实例，我需要编写

var s = new DataContractSerializer(typeof(MyCustomClass));

代替

var s = new DataContractSerializer<MyCustomClass>();

我不是在寻找关于哪种方式是“最好”的辩论，我很想知道是否有任何充分的理由去做任何一种方式。 :)

更多示例（取自我的头脑）是： - System.Xml.Serialization.XmlSerializer（构造函数） - System.ServiceModel.ServiceHost（构造函数和几个方法） - System.Web.Mvc.ModelBinderAttribute

Answer 1

在XmlSerializer的情况下，它早于 generics，这是一个很好的理由 - 但还有其他理由。 在序列化代码上花了很多时间后，我痛苦地知道（在库代码中很常见）通常你所拥有的只是Type 。 简单地说，像 WCF 这样的库代码不能始终是通用的——这将是很多开销和复杂性。 例如，它可能刚刚从元素名称（或其他标记）中查找了Type 。 它事先不知道类型，所以它不可能是“通用的”（在<T>意义上）。

在那些有Type的情况下，您可以使用MakeGenericMethod等，但这是很多开销，并且实际上可能会破坏 CF 等（您最终会开始出现缺失方法错误）。

碰巧的是，我最近重写了整个序列化库，从使用 generics 作为主要 API 到使用Type作为主要 API。 幸运的是，这意味着旧方法只需将typeof(T)与新方法一起使用，因此效果很好。

Answer 2

您示例中的前两个类 - XmlSerializer 和 ServiceHost - 是在 generics 存在之前设计的。 据推测，微软可以为这些处理 generics 的类发明替代品，但这并没有发生。

Generics 通常不是必需的：如果方法的签名不依赖于类型，那么无论是传递typeof(MyCustomClass)还是调用Method<MyCustomClass>都不会对调用者产生任何影响。 拥有 System.Type 参数通常更有用：如果您正在编写自己的反射代码，通常无论如何都会拥有 System.Type。 如果您所拥有的只是一个 System.Type，那么调用泛型方法要困难得多。