design patterns - क्या UnitOfWork लेन-देन के बराबर है? या यह उससे अधिक है?




design-patterns data-access-layer (2)

इंटरनेट UnitOfWork पैटर्न के बारे में जानकारी से भरा है; यहां तक ​​कि एसओ भी अपवाद नहीं है।

मुझे अभी भी इसके बारे में कुछ समझ नहीं आ रहा है। मेरी समझ में UnitOfWork = Transaction in DB । बस इतना ही; न कुछ ज्यादा, न कुछ कम।

क्या ये सही है?

मेरा भ्रम यह है कि इसे अलग-अलग ORM s में कैसे लागू किया जाता है। NHibernate केवल एक Transaction से अधिक के लिए ISession का उपयोग करता है। Dapper आप के लिए सब कुछ छोड़ देता है।

यहाँ मेरा प्रश्न किसी भी ORM या तकनीक पर विचार किए बिना केवल डिज़ाइन पैटर्न के बारे में है।

यदि यह केवल Transaction से अधिक है, तो कृपया बताएं कि कैसे।

संपादित करें 1

this लिंक का संदर्भ जैसा कि @David ओसबोर्न द्वारा उत्तर में सुझाया गया है।

कार्य की एक इकाई व्यापार लेनदेन के दौरान आपके द्वारा की जाने वाली हर चीज पर नज़र रखती है जो डेटाबेस को प्रभावित कर सकती है। जब आप काम पूरा कर लेते हैं, तो यह आपके काम के परिणामस्वरूप डेटाबेस को बदलने के लिए आवश्यक हर चीज का पता लगाता है।

तो इसका मतलब है UnitOfWork DBTransaction और More है

इसके बाद यह अतिरिक्त जिम्मेदारियां हैं: -

  • काम के इस सत्र में आपने जो कुछ भी बदला, डाला, हटाया, उसकी स्थिति बनाए रखें।

  • इस स्थिति के आधार पर, काम पूरा होने पर डेटाबेस को संशोधित करें।

हालांकि उपरोक्त उद्धरण में स्पष्ट रूप से उल्लेख नहीं किया गया है, लेकिन यह प्रश्नों की बैचिंग को भी नियंत्रित कर सकता है।

क्या अब मेरी समझ सही है?


एक UnitOfWork एक व्यापारिक लेनदेन है। जरूरी नहीं कि एक तकनीकी लेन-देन (डीबी लेनदेन) लेकिन अक्सर तकनीकी लेनदेन से बंधा हो।

this इसे परिभाषित किया गया है

एक व्यापारिक लेनदेन से प्रभावित वस्तुओं की एक सूची को बनाए रखता है और परिवर्तनों के लेखन और समन्वयन समस्याओं के समाधान का समन्वय करता है।

यह परिभाषित नहीं करता है कि परिवर्तन कैसे लिखे गए हैं और न ही भंडारण प्रकार।

एक प्रशंसा एक में परिवर्तन लिख सकता है

  • SQL का उपयोग कर डेटाबेस
  • धाराओं का उपयोग कर फाइल सिस्टम
  • http अनुरोधों का उपयोग करके दृढ़ता सेवा
  • विधि इनवोकेशन का उपयोग करके वितरित कैश या इन-मेमोरी मेमोरी

एक UnitOfWork (व्यावसायिक लेन-देन) व्यावसायिक वस्तुओं में परिवर्तन एकत्र करता है और यह सुनिश्चित करता है कि अन्य व्यावसायिक लेनदेन केवल मान्य व्यावसायिक ऑब्जेक्ट देखेंगे।

उदाहरण के लिए जब आपका आवेदन एक उपयोग के मामले को निष्पादित करता है तो यह व्यापारिक वस्तुओं को संशोधित करता है। यदि दो व्यावसायिक लेनदेन (आमतौर पर मामलों का उपयोग करते हैं) को समानांतर में निष्पादित किया जाता है, तो आपके आवेदन को उन परिवर्तनों के बारे में ध्यान रखना चाहिए जो प्रत्येक व्यवसाय लेनदेन करता है और वह समय जब अन्य व्यावसायिक लेनदेन उन्हें देखेंगे।

तकनीकी रूप से यह अक्सर डीबी लेनदेन का उपयोग करके किया जाता है। इस प्रकार काम की एक इकाई आमतौर पर एक डीबी लेनदेन है।

दृढ़ता को संभालने के लिए ओआरएम-फ्रेमवर्क का उपयोग करने वाले अनुप्रयोगों में आमतौर पर शब्द की इकाई और डीबी लेनदेन के बीच एक-से-एक संबंध होता है। तो काम की एक इकाई और एक डीबी लेनदेन के बीच का अंतर आमतौर पर डेवलपर्स के लिए प्रासंगिक नहीं होता है।


यह एक तार्किक / व्यावसायिक लेनदेन के दौरान वस्तुओं की [दृढ़ता] स्थिति को ट्रैक करने के लिए ORM उपकरणों की आवश्यकता से AFAIK की this करता है।

कार्य की एक इकाई इसे कैसे प्रबंधित करती है, और अंतर्निहित भंडारण प्रौद्योगिकी और संग्रहीत वस्तुओं के साथ इसका संबंध, एक कार्यान्वयन विवरण है।

बीच में कई एसक्यूएल बयानों के साथ एक डेटाबेस लेनदेन, यकीनन काम की एक इकाई भी है। हालाँकि, मुख्य अंतर, मुझे लगता है, यह है कि काम की इकाई, जैसा कि पैटर्न में परिभाषित किया गया है, विस्तार के उस स्तर को एक वस्तु स्तर पर सार कर दिया है।







unit-of-work