PostSharp। लेन-देन प्रबंधन

जब मैंने आखिरी बार एक कंपनी को सलाह दी थी, तो हमने आंतरिक एसओए ढांचे पर चर्चा की थी जिसे उद्यम डेटाबेस के साथ बातचीत करनी चाहिए। यह ढांचा केवल नाम से SOA था, पूरी तरह से होमग्रोन, और सबसे दुख की बात है, यह आईटी विभाग के प्रमुख का "पसंदीदा प्रोजेक्ट" था। यह सुरक्षित नहीं था और संदिग्ध प्रौद्योगिकियों और समाधानों पर बनाया गया था। सामान्य तौर पर, यह एक निश्चित समस्या को हल करने के लिए बनाया गया था, जो या तो मौजूद नहीं है, या इसे सरल तरीकों से हल नहीं किया जा सकता है। मेरी टीम इस ढांचे की संरचना से बेहद निराश थी। लेकिन, एक सलाहकार के रूप में, अक्सर समस्या को हल करने के तरीकों पर विचार करना आवश्यक होता है, आप ग्राहक को केवल यह नहीं बता सकते हैं कि उसका उत्पाद "खराब" है, आपको पहले खुद में अपना विश्वास बनाना होगा, और उसके बाद ही अधिक गंभीर समस्याओं का समाधान करना होगा। एक तरह से या किसी अन्य, इस तरह की प्रक्रिया में वर्षों लग सकते हैं, और यह सब उस कंपनी पर निर्भर करता है जिसमें ऐसे परिवर्तन होंगे। तब मैंने इस समस्या को हल करने के लिए एक पहलू-उन्मुख ढांचे का उपयोग शुरू करने के बारे में सोचा।

इन कार्यक्रमों के लिए सभी स्रोत कोड GitHub पर उपलब्ध है

उसी समय, हमें इस ढांचे के साथ विफल होने के लिए बर्बाद किया गया था, क्योंकि यह बहु-थ्रेडेड अनुप्रयोगों (उदाहरण के लिए, वेब सर्वर के लिए) के लिए बिल्कुल इरादा नहीं है। इस वजह से, दुर्घटनाएं लगातार होती हैं, और कभी-कभी यह बस काम नहीं कर सकती या शुरू नहीं हो सकती है। हमें इस गड़बड़ और अराजकता के आसपास काम करने वाले और अच्छी तरह से काम करने वाले अनुप्रयोगों का निर्माण करना था, सबसे पहले क्योंकि हम ग्राहक कंपनी के हिस्से पर एक निश्चित स्तर का विश्वास बनाना चाहते हैं। हमने इस कंपनी के लिए पहले से जो किया है वह पिछले लेखों में देखा जा सकता है: यह लॉगिंग और एरर ट्रैपिंग है। यह अच्छी तरह से काम किया, और अंत उपयोगकर्ता से सभी "गंदा चीजों" को छिपा दिया। हालांकि, इस प्रणाली का उपयोग करने के लिए, इसके साथ संपर्क में आने वाले कोड के प्रत्येक टुकड़े की रक्षा करना आवश्यक है। और ऐसा करने से मैं बहुत जल्दी थक जाता था। आखिरकार, कल्पना करें: प्रत्येक विधि के लिए जिसे फ्रेमवर्क में बुलाया गया था या कक्षाओं के गुणों और क्षेत्रों के मूल्यों को पढ़ा गया था, उसी चेक को चलाने के लिए आवश्यक था, और इसे ज़्यादा मत करो: अन्यथा हम प्रदर्शन खो देते हैं।
हालांकि, पुरानी परियोजनाओं के बारे में बात करना बंद कर दें , व्यापार के बारे में बात करते हैं: आप लेन-देन का प्रबंधन करने के लिए PostSharp का उपयोग कर सकते हैं, भले ही आप घर-निर्मित ढांचे पर अपना आवेदन बनाएं या नहीं। यहाँ एक सरल OnMethodBoudaryAspect उदाहरण है जो आपको विशिष्ट लेनदेन समर्थन की मूल बातें का एक उदाहरण देगा:

[Serializable] public class TransactionScopeAttribute : OnMethodBoundaryAspect { [NonSerialized] private ICharityService _charityService; private string _methodName; private string _className; public override void CompileTimeInitialize(MethodBase method, AspectInfo aspectInfo) { _className = method.DeclaringType.Name; _methodName = method.Name; } public override void RuntimeInitialize(System.Reflection.MethodBase method) { // in practice, the begin/rollback/commit might be in a more general service // but for convenience in this demo, they reside in CharityService alongside // the normal repository methods _charityService = new CharityService(); } public override void OnEntry(MethodExecutionArgs args) { _charityService.BeginTransaction(); } public override void OnException(MethodExecutionArgs args) { _charityService.RollbackTransaction(); var logMsg = string.Format("exception in {0}.{1}", _className, _methodName); // do some logging } public override void OnSuccess(MethodExecutionArgs args) { _charityService.CommitTransaction(); } } 

सब कुछ वास्तव में सरल है और मेरे पुराने लेखों के बारे में बिल्कुल नया नहीं है। ध्यान दें कि लेन-देन रोलबैक के मामले में एक अपवाद को फेंकना अच्छा होगा, और यह डिफ़ॉल्ट रूप से किया जाता है (कोड में जो onException उठाता है)। आपको बस उन तरीकों को चिह्नित करना है जिनमें आपको [TransactionScope] विशेषता के साथ लेन-देन का समर्थन करने की आवश्यकता है, और आप एक सरल पहलू में फिर से कोशिश / पकड़ शुरू / प्रतिबद्ध / रोलबैक कोड लिखने से खुद की रक्षा करेंगे। हमने एक स्थान पर समान कोड भी निकाला, और इसी तरह हम अपवादों को पकड़ने के लिए लॉगिंग या कुछ विशेष विधि जोड़ सकते हैं।
उन मामलों में से एक जहां ऊपर कोड ठीक से काम नहीं करेगा, एक नेस्टेड लेनदेन है। ऊपर मेरे कोड में, शुरुआत / कमिट / रोलबैक विधियां केवल डमी हैं जो वास्तव में कुछ भी नहीं करती हैं। आपके द्वारा विकसित किए जा रहे अंतिम एप्लिकेशन में, लेनदेन प्रबंधन डेटा एक्सेस पद्धति पर अत्यधिक निर्भर है। यदि आप ADO.NET कनेक्शन, जैसे SqlConnection, ODBC, Oracle, आदि का उपयोग करते हैं, तो आप लेनदेन कार्यान्वयन को सरल और समर्थित बनाने के लिए TransactionScope (पहलू नाम के साथ भ्रमित न करें) का सबसे अधिक उपयोग करेंगे। हालांकि, यदि आप कुछ स्टैंड-अलोन तकनीक का उपयोग करते हैं, तो आप पूरी तरह से अलग एपीआई का उपयोग करेंगे और आपको अतिरिक्त समाधान की आवश्यकता होगी।
अब जब हमारे पास लेनदेन समर्थन का मूल पहलू है, तो आइए अपने मूल उदाहरण पर वापस आते हैं। मेरे द्वारा उपयोग की जाने वाली सेवा लगातार टूट रही है। इसलिए, मैं एक चक्र लिखूंगा जो ऑपरेशन को सफल होने तक करने की कोशिश करेगा। और, ज़ाहिर है, मैं नहीं चाहता कि प्रयास स्थिर रहें और एक अंतहीन चक्र में विकसित हों। इसलिए, हम प्रयासों की संख्या पर प्रतिबंध लगाते हैं। इसके अलावा, हम यह सुनिश्चित करें कि एक DataException असफल प्रयास का संकेत है, और अन्य सभी अपवाद हमें बताते हैं कि ऑपरेशन को आगे बढ़ाने के सभी प्रयास बेकार हैं। इसलिए, हम ऐसे अपवादों की प्रतिज्ञा करते हैं और प्रयास करना बंद कर देते हैं:

 [Serializable] public class TransactionScopeAttribute : MethodInterceptionAspect { [NonSerialized] private ICharityService _charityService; [NonSerialized] private ILogService _logService; private int _maxRetries; private string _methodName; private string _className; public override void CompileTimeInitialize(MethodBase method, AspectInfo aspectInfo) { _methodName = method.Name; _className = method.DeclaringType.Name; } public override void RuntimeInitialize(System.Reflection.MethodBase method) { _charityService = new CharityService(); _logService = new LogService(); _maxRetries = 4; // you could load this from XML instead } public override void OnInvoke(MethodInterceptionArgs args) { var retries = 1; while (retries <= _maxRetries) { try { _charityService.BeginTransaction(); args.Proceed(); _charityService.CommitTransaction(); break; } catch (DataException) { _charityService.RollbackTransaction(); if (retries <= _maxRetries) { _logService.AddLogMessage(string.Format( "[{3}] Retry #{2} in {0}.{1}", _methodName, _className, retries, DateTime.Now)); retries++; } else { _logService.AddLogMessage(string.Format( "[{2}] Max retries exceeded in {0}.{1}", _methodName, _className, DateTime.Now)); _logService.AddLogMessage("-------------------"); throw; } } catch (Exception ex) { _charityService.RollbackTransaction(); _logService.AddLogMessage(string.Format( "[{3}] {2} in {0}.{1}", _methodName, _className, ex.GetType().Name, DateTime.Now)); _logService.AddLogMessage("-------------------"); throw; } } _logService.AddLogMessage("-------------------"); } } 

हाँ, यह थोड़ा भयावह लगता है! लेकिन चिंता मत करो, चलो इसे अलग ले लो। CompileTimeInitialize और RuntimeInitialize पहले बताए गए लोगों से बहुत अलग नहीं दिखते हैं: वे सिर्फ कक्षा और विधि के नाम याद रखते हैं और हमें उन सेवाओं को आरंभ करते हैं जिनकी हमें आवश्यकता होती है।
OnInvoke पद्धति के लिए, आइए चार संभावित कार्य परिदृश्यों को देखें:

• यदि विधि अपवाद के बिना काम करती है, तो इसका मतलब है कि सब कुछ ठीक काम करता है।
• विधि विफल हो जाती है और एक DataException को फेंकता है, और हम अभी तक रिट्रीट की संख्या में सीमा तक नहीं पहुंचे हैं। यह कोड पहले कैच {} ब्लॉक के if / else स्टेटमेंट के पहले भाग में है
• विधि विफल हो जाती है और एक DataException को फेंकता है, और हम पुनर्प्रयास की संख्या पर सीमा तक पहुंच गए हैं। यह कोड पहले कैच {} ब्लॉक के if / else स्टेटमेंट के दूसरे भाग में है
• विधि एक अन्य अपवाद को फेंकती है, एक महत्वपूर्ण त्रुटि और रिट्रीज की असंभवता को इंगित करती है। दूसरे ब्लॉक कैच {} का कोड इस स्थिति के लिए जिम्मेदार है

अपने सरल आवेदन में, मैंने CharityService सेवा बनाई, जो 50% मामलों में DataException त्रुटि के साथ क्रैश होती है, और शेष 50% में यह सफलतापूर्वक समाप्त होती है। इसके अलावा, लगभग 50 में से 1 कॉल में, यह एक DataException नहीं लौटाता है, लेकिन कुछ अन्य। यदि आप उदाहरण चलाते हैं, तो आप लॉग विंडो देख सकते हैं, जिसमें बड़ी संख्या में प्रयास रिकॉर्ड किए जाएंगे, और आरंभ, रोलबैक और कमिट कॉल। इसके अलावा, यदि प्रोग्राम अनुमति से अधिक प्रयास करता है, या यदि कोई अपवाद नहीं है, तो उपयोगकर्ता को एक त्रुटि संदेश दिखाई देगा, जो कि एक DataException नहीं था।

इस पहलू का उपयोग करते हुए, आप इस प्रकार की समस्याओं को हल करने में अपने आवेदन को कुछ मजबूती प्रदान करते हैं। पहलू कोड बड़ा हो गया है लेकिन यह प्रबंधनीय है। यदि आप कुछ और अधिक जटिल प्राप्त करना चाहते हैं, तो एक रिफलेक्टिंग होगा: वर्गों और विधियों में विभाजन, और अन्य संचालन। एक सूत्र में एक विधि से बहु-थ्रेडेड कॉल बनाने के लिए आप इस विधि का उपयोग कर सकते हैं।

संदर्भ:

• आधिकारिक वेबसाइट
• PostSharp। विलंबित निर्भरता लोड हो रहा है
• PostSharp। लॉगिंग और ऑडिट कार्य
• हम कैशिंग समस्या का समाधान करते हैं
• इंटेल ब्लॉग्स: पोस्टशार्प। भाग 1
• इंटेल ब्लॉग्स: पोस्टशार्प। विकल्प
• पहलू उन्मुख प्रोग्रामिंग बनाम निर्भरता इंजेक्शन