DateTimeOffset (सख्त)

आज सुबह मेरे दोस्त kirillkos एक समस्या में भाग गया।

समस्या कोड

यहाँ उसका कोड है:

class Event { public string Message {get;set;} public DateTime EventTime {get;set;} } interface IEventProvider { IEnumerable<Event> GetEvents(); } 

और फिर कई, IEventProvider कई कार्यान्वयन जो विभिन्न तालिकाओं और डेटाबेस से डेटा IEventProvider करते हैं।

समस्या : इन सभी ठिकानों में, सब कुछ अलग-अलग समय क्षेत्रों में है। तदनुसार, जब यूआई को घटनाओं को आउटपुट करने की कोशिश की जाती है, तो सब कुछ बहुत उलझन में है।

होल्सबर्ग की जय, हमारे पास प्रकार हैं, क्या वे हमें बचा सकते हैं!

प्रयास 1

 class Event { public string Message {get;set;} public DateTimeOffset EventTime {get;set; } } 

DateTimeOffset शानदार प्रकार है, यह UTC के बारे में ऑफसेट जानकारी संग्रहीत करता है। यह MS SQL और Entity Framework द्वारा पूरी तरह से समर्थित है (और संस्करण 6.3 में यह और भी बेहतर समर्थित होगा)। हमारी कोड शैली में, सभी नए कोड के लिए यह अनिवार्य है।

अब हम इन समान प्रदाताओं से जानकारी एकत्र कर सकते हैं और लगातार, प्रकारों पर भरोसा करते हुए, UI पर सब कुछ प्रदर्शित करते हैं। जीत!

समस्या : DateTimeOffset स्पष्ट रूप से DateTime से परिवर्तित हो सकती है।
निम्नलिखित कोड ठीक संकलित करता है:

 class Event { public string Message {get;set;} public DateTimeOffset EventTime {get;set; } } IEnumerable<Event> GetEvents() { return new[] { new Event() {EventTime = DateTime.Now, Message = "Hello from unknown time!"}, }; } 

ऐसा इसलिए है क्योंकि DateTimeOffset एक अंतर्निहित कास्टिंग ऑपरेटर परिभाषित है:

 // Local and Unspecified are both treated as Local public static implicit operator DateTimeOffset (DateTime dateTime); 

यह वह नहीं है जो हमें चाहिए। हम सिर्फ प्रोग्रामर को सोचना चाहते थे, जब कोड लिख रहा था: "लेकिन यह घटना किस समय और किस क्षेत्र में हुई?" ज़ोन कहाँ से मिलेगा? ” अक्सर पूरी तरह से अलग क्षेत्रों से, कभी-कभी संबंधित तालिकाओं से। और फिर बहुत आसानी से बिना सोचे समझे गलती करना।

धिक्कार है निहित धर्मांतरण!

प्रयास २

जब से मैंने सुना है एक हथौड़ा स्थिर विश्लेषक , मुझे सब कुछ लगता है नाखून उनके लिए उपयुक्त मामले। हमें एक स्थिर विश्लेषक लिखने की आवश्यकता है जो इस अंतर्निहित रूपांतरण को प्रतिबंधित करता है, और बताता है कि ... यह बहुत काम की तरह दिखता है। वैसे भी, यह जाँचने के लिए संकलक का काम है। अभी के लिए, इस विचार को क्रिया के रूप में रखें।

प्रयास ३

अब, अगर हम एफ # की दुनिया में होंगे, तो किरिलकोस ने कहा।
हम तब:

 type DateTimeOffsetStrict = Value of DateTimeOffset 

और आगे सुधार के साथ नहीं आया किसी तरह का जादू हमें बचा लेता। यह अफ़सोस की बात है कि वे हमारे कार्यालय में F # नहीं लिखते हैं, और हम वास्तव में Kirillkos को नहीं जानते हैं →

प्रयास ४

क्या C # में कुछ नहीं किया जा सकता है? यह संभव है, लेकिन आपको आगे और पीछे परिवर्तित करके पीड़ा दी जाती है। बंद करो, लेकिन हमने अभी देखा कि आप कैसे अंतर्निहित रूपांतरण कर सकते हैं!

 /// <summary> /// Same as <see cref="DateTimeOffset"/> /// but w/o implicit conversion from <see cref="DateTime"/> /// </summary> public readonly struct DateTimeOffsetStrict { private DateTimeOffset Internal { get; } private DateTimeOffsetStrict(DateTimeOffset @internal) { Internal = @internal; } public static implicit operator DateTimeOffsetStrict(DateTimeOffset dto) => new DateTimeOffsetStrict(dto); public static implicit operator DateTimeOffset(DateTimeOffsetStrict strict) => strict.Internal; } 

इस प्रकार के बारे में सबसे दिलचस्प बात यह है कि यह DateTimeOffset से अंतर्निहित रूप से आगे और पीछे परिवर्तित होता है, लेकिन DateTime से इसे DateTime रूप से परिवर्तित करने के प्रयास से संकलन त्रुटि हो जाएगी, दिनांक समय से रूपांतरण केवल स्पष्ट रूप से संभव है। संकलक निहित रूपांतरणों की "श्रृंखला" को नहीं कह सकता है, यदि वे हमारे कोड में परिभाषित किए गए हैं, तो मानक इसे मना करता है ( एसओ से उद्धरण )। अर्थात्, यह इस तरह काम करता है:

 class Event { public string Message {get;set;} public DateTimeOffsetStrict EventTime {get;set; } } IEnumerable<Event> GetEvents() { return new[] { new Event() {EventTime = DateTimeOffset.Now, Message = "Hello from unknown time!"}, }; } 

लेकिन ऐसा नहीं है:

 IEnumerable<Event> GetEvents() { return new[] { new Event() {EventTime = DateTime.Now, Message = "Hello from unknown time!"}, }; } 

हमें क्या चाहिए था!

परिणाम

हमें अभी तक नहीं पता है कि हम इसे लागू करेंगे या नहीं। केवल हर कोई DateTimeOffset का आदी हो चुका है, और अब इसे हमारे प्रकार के साथ बदलना गूंगा है। हां, और निश्चित समस्याओं के लिए ईएफ, एएसपी.नेट पैरामीटर बाइंडिंग और एक हजार स्थानों पर स्तर सामने आएगा। लेकिन समाधान खुद मुझे दिलचस्प लगता है। मैंने उपयोगकर्ता इनपुट की सुरक्षा की निगरानी के लिए इसी तरह की तरकीबों का इस्तेमाल किया है - मैंने UnsafeHtml टाइप UnsafeHtml , जिसे अंतर्निहित रूप से एक स्ट्रिंग से परिवर्तित किया गया है , लेकिन आप इसे वापस स्ट्रिंग या IHtmlString केवल सैनिटाइज़र कहकर परिवर्तित कर सकते हैं।