我对IConvertible
有问题,简而言之:如果DateTimeOffset
实现了IConvertible
,我就不会有问题。
你们不能使用扩展方法来实现一个接口,所以道路是封闭的。结构DateTimeOffset不是分部的,因此不能以这种方式进行扩展。
在阅读一些MSDN文档时,我发现了TypeCode
枚举,这似乎是IConvertable正常工作所必需的。令我失望的是,枚举也不包含TimeSpan,这关闭了使用具有DateTime
和TimeSpan
(即DateTimeOffset
=P)的类似Tuple
的结构的选项
我的问题如下:您将如何实现具有基本IConvertable或类似支持的DateTimeOffset等价物?
该实现涉及一个具有[index,TType] where TType : IConvertible
(包括setter、getter和try-ggetter)功能的高级懒惰字典实现,并且它需要能够存储特定于时区的数据。
到目前为止我的想法:
-
创建一个新的
ISuperConvertible
接口,它实际上只是对IConvertible
的扩展,并使DateTimeOffset
成为一个特例。这将打破我们对IC的普遍支持,但适用于这个非常具体的案例。利弊 -
使用两个"槽"存储
DateTimeOffset
s,一个用于DateTime
,一个用作int
半小时偏移量(所有时区都不是整小时=/)。然后我们就失去了cache[ApplicationStrings.LastUpdate, default : DateTimeOffset.Min]
的功能。
这些代表了我的主要思想,即打破DateTimeOffset
保持IConvertible
或打破IConvertible
保持DateTimeOffset
。
我对C#的内在特性还很陌生,所以任何见解都会有所帮助。你有什么想法?
编辑:附加:
- 现在有一个使用DateTime(固定时区)的有效解决方案,但现在也需要时区,最佳方案是只在任何地方使用DateTimeOffset。问题的本质不是重构,而是我的具体问题
- 它是一个相当大的应用程序,它使用实体框架和其他更模糊的框架来与不同的服务和存储进行通信,因此保持它为简单的系统定义类型不会破坏LINQ-to-X优化等(我不知道自己做这些有多难)
- 我反对拆分数据,因为我不知道什么时候会有另一个人出现并注意到有一个DateTime用于时间戳,并且使用它时不考虑偏移量(时区)
您可以在DateTimeOffset上创建自己的包装类,实现IConvertable。该类将具有DateTimeOffset属性,您将使用该属性作为包装器属性和方法。并且您为它实现了IConvertable的方法。示例:
public class DTOffset:IConvertible
{
private DateTimeOffset DateTimeOffset;
//Implementation of IConvertible
public long ToInt64(IFormatProvider provider)
{
return DateTimeOffset.Ticks;
}
public DateTime ToDateTime(IFormatProvider provider)
{
DateTimeOffset.DateTime;
}
//and so on
//wrapper properites of DateTimeOffset:
public int DayOfYear{get{return DateTimeOffset.DayOfYear;}}
public DateTime Date{get{return DateTimeOffset.Date;}}
//and so on
}