为什么在某些.NET框架类中选择了System.Type参数而不是泛型？

Question

我注意到.NET框架中的几个内置类/方法接受了System.Type的参数，其中（在我看来）使用泛型会更清晰。 例如，要创建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的情况下，它优先于泛型，这是一个很好的理由 - 但还有其他原因。花了很多时间在序列化代码上，我非常痛苦地知道（在库代码中非常常见）经常只有Type 。简单地说，像WCF这样的库代码在整个过程中都不是通用的 - 这将是很多开销和复杂性。例如，它可能只是从元素名称（或其他标记）中查找Type。它不提前知道类型，所以它不可能是“通用的”（在<T>意义上）。

在你拥有Type的情况下，你可以使用MakeGenericMethod等，但这是一个很大的开销，实际上可以破坏CF等（你最终会开始丢失方法错误）

实际上，我最近重写了一个完整的序列化库，使用泛型作为主要API，使用Type作为主要API。幸运的是，这意味着旧方法只使用typeof(T)和新方法，因此效果很好。

Answer 2

您的示例中的前两个类 - XmlSerializer和ServiceHost - 是在存在泛型之前设计的。据推测，微软可以为这些涉及仿制药的类创造替代品，但这种情况并没有发生。

泛型通常不是必需的：如果方法的签名不依赖于类型，那么对于调用者来说它是否通过typeof(MyCustomClass)或调用Method<MyCustomClass>不应该有任何区别。拥有一个System.Type参数通常更有用：如果你正在编写自己的反射代码，那么你通常会有一个System.Type。如果你所拥有的只是一个System.Type，那么调用泛型方法要困难得多。