我已经在实用程序库中编写了一些非常依赖的方法。第一种是将任何Type转换为其对应的Nullable <Type>形式的方法:
public static Type GetNullableType(Type TypeToConvert)
{
if (TypeToConvert == null)
return null;
if (IsTypeNullable(TypeToConvert))
return TypeToConvert;
if (TypeToConvert.IsValueType && TypeToConvert != typeof(void))
return typeof(Nullable<>).MakeGenericType(TypeToConvert);
return null;
}
第二种方法只是报告给定的Type是否可为空。此方法由第一个调用,并且分别有用:
public static bool IsTypeNullable(Type TypeToTest)
{
if (TypeToTest == null)
return false;
if (!TypeToTest.IsValueType)
return true;
return TypeToTest.IsGenericType && TypeToTest.GetGenericTypeDefinition() == typeof(Nullable<>);
}
上面的IsTypeNullable实现每次都像冠军一样工作,但是在最后一行代码中有些冗长和缓慢。以下代码主体与上面的IsTypeNullable相同,但最后一行代码更简单,更快捷:
if (TypeToTest == null)
return false;
if (!TypeToTest.IsValueType)
return true;
return Nullable.GetUnderlyingType(TypeToTest) != null;
请享用!
标记
PS-关于“可空性”
我应该在另一篇文章中重复有关可空性的声明,该声明直接适用于正确解决此主题。也就是说,我认为这里讨论的重点不应是如何检查对象是否为通用Nullable类型,而是应该是否可以为该类型的对象分配null值。换句话说,我认为我们应该确定对象类型是否可为空,而不是它是否可为空。区别在于语义上,即确定可为空性的实际原因,通常这很重要。
在使用对象的类型直到运行时可能未知的系统(Web服务,远程调用,数据库,提要等)中,一个共同的要求是确定是否可以为该对象分配空值,或者该对象是否可能包含空值。对非空类型执行此类操作可能会产生错误,通常是异常,这在性能和编码要求方面都非常昂贵。为了采取主动避免此类问题的首选方法,有必要确定任意类型的对象是否能够包含null。即,它通常是否为“可为空”。
在非常实际和典型的意义上,.NET术语中的可为空性完全不一定意味着对象的类型是可为空的形式。实际上,在许多情况下,对象具有引用类型,可以包含空值,因此都可以为空。这些都没有Nullable类型。因此,出于实用目的,在大多数情况下,应针对可为空性的一般概念进行测试,而不是依赖于实现的可为性概念。因此,我们不应该只专注于.NET Nullable类型,而应该将我们对它的要求和行为的理解纳入到专注于一般的,实用的nullability概念的过程中。