Architecture-center: ProductCommandHandler (CQRS) और ProductRepository (पारंपरिक आर्क) में क्या अंतर है?

को निर्मित 15 नव॰ 2019 · 5टिप्पणियाँ · स्रोत: MicrosoftDocs/architecture-center

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

public class ProductRepository {
  void AddNewProduct(Product newProduct) {
    ...
  }
  void RateProduct(int productId, int userId, int rating) {
    var product = repository.Find(productId);
    if (product != null)
    {
      product.RateProduct(userId, rating);
      repository.Save(product);
    }
  }
}

दस्तावेज़ विवरण

इस अनुभाग को संपादित न करें।

आईडी: 0c0ec92e-c237-f3a6-1835-f2078486dcb3
संस्करण स्वतंत्र आईडी: f597c9a2-f18f-3722-57f9-acd535472b0b
सामग्री: कमांड और क्वेरी रिस्पॉन्सिबिलिटी सेग्रीगेशन (CQRS) पैटर्न - क्लाउड डिज़ाइन पैटर्न
सामग्री स्रोत: डॉक्स/पैटर्न/cqrs.md
सेवा: वास्तुकला केंद्र
उप-सेवा: क्लाउड-फंडामेंटल्स
GitHub लॉगिन: @ dragon119
Microsoft उपनाम: pnp

Pri1 architecture-centesvc assigned-to-author cloud-fundamentalsubsvc product-question triaged

स्रोत

martinmthomas

👍1

सबसे उपयोगी टिप्पणी

@martinmthomas वास्तव में कमांड हैंडलर एक भंडार नहीं है। यह एक भंडार का उपयोग करता है।

कमांड हैंडलर "उपयुक्त होने पर वास्तविक आदेशों को संसाधित करने" के लिए है। उदाहरण में ProductsCommandHandler वर्ग को इसके निर्माता में IRepository<Product> प्राप्त होता है।

मान लें कि उपयोगकर्ता उत्पाद को 5555 से 4 स्टार रेट करने जा रहा है।

उपयोगकर्ता एक इंटरफ़ेस देखता है। मान लें कि एक वेब पेज (एक स्थानीय .exe प्रोग्राम हो सकता है या जो भी हो, आइए एक वेबसाइट की कल्पना करें)।
उपयोगकर्ता एक बटन पर क्लिक करता है। मान लें कि यह एक AJAX POST को डेटा {"product":"5555","stars":4} साथ रूट/दर पर जाने के लिए ट्रिगर करता है
POST मार्ग में एक नियंत्रक है। यह नियंत्रक "राइट" ऑपरेशन से जुड़ा है क्योंकि यह POST कॉल से आता है।
शास्त्रीय दृष्टिकोण में यहां नियंत्रक केवल क्लासिक उत्पाद भंडार को लोड करेगा और उत्पाद को 5555 लोड करेगा। फिर उत्पाद को "अब आपको 4 स्टार रेट किया गया है" और सहेजें।
इस दृष्टिकोण में, नियंत्रक RateProduct कमांड बनाता है और उत्पाद 5555, सितारे 4 में भरता है। उदाहरण में यह यह भी भरता है कि रेटिंग कौन है।
इस समय, नियंत्रक "कमांड भेजता है" लिखने के लिए मॉडल। आपके पास यहां 2 विकल्प हैं: एक कमांड हैंडलर को आमंत्रित करें या इसे कतारबद्ध करें।
कहें कि आपके पास कतार नहीं है। फिर आप अपने नियंत्रक में CommandHandler प्राप्त करें (शायद निर्भरता इंजेक्शन द्वारा) और बस वहां कमांड रखें: h.Handle(c); जहां c रेटप्रोडक्ट कमांड है।
कहो आपके पास एक कतार है। फिर आप अपने नियंत्रक (शायद निर्भरता इंजेक्शन द्वारा) में कतार प्राप्त करते हैं और वहां केवल आदेश को संलग्न करते हैं: q.Queue(c);
इस अंतिम स्थिति में, कतार का श्रोता कमांड को कतार से बाहर ले जाएगा और इसके बजाय कमांड हैंडलर को कॉल करेगा।
एक थिर्स विकल्प (अनुशंसित) के रूप में, आपका नियंत्रक यह नहीं चुनता है कि कमांड को समकालिक रूप से संसाधित किया जा रहा है (हैंडलर प्राप्त करें) या अतुल्यकालिक रूप से (कतार प्राप्त करें) लेकिन एक "जेनेरिक दृष्टिकोण" का उपयोग करना चाहिए जो कमांड बस का उपयोग करना है रखे गए। मान लें कि कमांड बस बी है, तो आप बी करेंगे। भेजें (सी); जहां c रेटप्रोडक्ट कमांड है।
इस तीसरे दृष्टिकोण के साथ आप कमांड हैंडलर को बस के अंत में रखते हैं, और आप मिडलवेयर को "बस से कमांड निकालने और इसे कतार में रखने" के लिए कॉन्फ़िगर कर सकते हैं।

तो 3 विकल्प: ए) हैंडलर प्राप्त करें, बी) कतार प्राप्त करें, सी) एक बस प्राप्त करें और इसे हैंडलर या कतार में आदेश भेजने का निर्णय लें।

आप जो भी दृष्टिकोण करते हैं ... "एक शास्त्रीय भंडार" के बारे में मुख्य अंतर यह है कि आप कभी भी नियंत्रक में ही भंडार का आह्वान नहीं कर रहे हैं। नियंत्रक "संस्थाओं को प्रबंधित करने के तरीके के बारे में नहीं जानता" (शास्त्रीय भंडार) लेकिन यह जानता है कि "संस्थाओं को करने के इरादे कैसे प्रबंधित करें" (कमांड हैंडलर)।

फिर यह कमांड हैंडलर है - जैसा कि इसका नाम कहता है- यह "कमांड को संभालता है" जो कहीं से आया था (एक एचटीएमएल वेब नियंत्रक, एक एपीआई नियंत्रक, एक कमांड लाइन, जो भी हो) जिसे एक इरादे के रूप में भेजा गया था और यह कमांडहैंडलर है (जो राइट साइड से संबंधित है) जो यह तय करता है कि उस कमांड का क्या करना है।

उदाहरण के लिए, कमांडहैंडलर उत्पाद प्राप्त करने के लिए रेपो का उपयोग कर सकता है, स्थिति सेट कर सकता है और सहेज सकता है (उदाहरण के लिए), लेकिन यह एक इवेंट लॉग को भी लिख सकता है, रीड-साइड को अपडेट करने के लिए तत्वों को ट्रिगर कर सकता है, बाहरी कनेक्टर को ट्रिगर कर सकता है या जो भी हो।

उत्पाद और उसके नियंत्रक का मूल्यांकन करने के लिए उपयोगकर्ता का कार्य-आधारित UI "जहां" अभिनीत / रेटिंग प्रणाली को रखा या संग्रहीत किया जाता है। कल्पना कीजिए कि आप स्क्रैच से एक सिस्टम डिज़ाइन करते हैं और उत्पाद वर्ग में पहले से ही रेटप्रोडक्ट() विधि शामिल है जैसे उदाहरण में। अच्छा।

लेकिन... क्या होगा यदि आपके पास उत्पाद के लिए "पुराने" दृष्टिकोण के साथ एक विरासत प्रणाली है। "मॉडल" (यानी: बिजनेस माइंड) में उत्पाद की कोई "रेटिंग" नहीं होती है। इसके बजाय मार्केटिंग वाला मौजूदा उत्पाद में रेटिंग "जोड़ना" चाहता है लेकिन सभी कंपनी इस बात से सहमत हैं कि यह एक "बाहरी चीज" है। क्या आप उत्पाद भंडार का उपयोग करेंगे? या शायद एक और सहायक भंडारण ताकि आप पहले से ही काम करने वाले और पूरी तरह से परीक्षण किए गए उत्पाद और उत्पाद रिपोजिटरी को "स्पर्श" न करें?

यदि आप आदेशों का उपयोग करते हैं, तो यह लेखन नियंत्रक को कोई आपत्ति नहीं है। वेब, एपीआई और सीएलआई सभी कमांड हैंडलर को "कमांड" भेजेंगे (या तो सीधे, कतार के माध्यम से या कमांड बस के माध्यम से जो हैंडलर या कतार में बदले में रूट करेगा) और वे भूल जाते हैं। फिर कमांड हैंडलर यह तय करेगा कि आपके स्रोत कोड के केंद्रीकृत और छोटे बिंदु में "RateProductCommand" के साथ क्या करना है, यह जिस तरह से इसे एप्लिकेशन कोड से नियंत्रित किया जाता है, इस प्रकार mantainability प्राप्त करना।

फिर हैंडलर तय करेगा कि क्या यह उत्पाद रिपोजिटरी या "उत्पाद की रेटिंग" को स्टोर करने के लिए अन्य दृष्टिकोण का उपयोग करने के लिए उपयुक्त है या नहीं।

तो, जवाब देने के लिए:

कमांडहैंडलर => का एंटाइट्स से कोई लेना-देना नहीं है। यह "उपयोगकर्ता के इरादे" को संभालता है (जो अंततः संस्थाओं को बदलने के लिए हो सकता है, इसलिए संभवतः कमांड हैंडलर एक रिपॉजिटरी का उपयोग करता है)।
रिपोजिटरी => एक निश्चित इकाई के लिए वास्तविक भंडारण।

मदद करने की उम्मीद है।
ज़ावी।

xmontero 18 जन॰ 2020

👍5

सभी 5 टिप्पणियाँ

@martinmthomas आपके प्रश्न के लिए धन्यवाद! हम समीक्षा करेंगे और उपयुक्त के रूप में एक अद्यतन प्रदान करेंगे।

KetanChawda-MSFT 15 नव॰ 2019

@MikeWasson यहाँ कोई विचार?

KetanChawda-MSFT 15 नव॰ 2019

AB#160217 - रिपोर्टिंग के लिए धन्यवाद - इस मुद्दे की समीक्षा की जा रही है

absheik 6 जन॰ 2020

मान लें कि उपयोगकर्ता उत्पाद को 5555 से 4 स्टार रेट करने जा रहा है।

उपयोगकर्ता एक इंटरफ़ेस देखता है। मान लें कि एक वेब पेज (एक स्थानीय .exe प्रोग्राम हो सकता है या जो भी हो, आइए एक वेबसाइट की कल्पना करें)।
उपयोगकर्ता एक बटन पर क्लिक करता है। मान लें कि यह एक AJAX POST को डेटा {"product":"5555","stars":4} साथ रूट/दर पर जाने के लिए ट्रिगर करता है
POST मार्ग में एक नियंत्रक है। यह नियंत्रक "राइट" ऑपरेशन से जुड़ा है क्योंकि यह POST कॉल से आता है।
शास्त्रीय दृष्टिकोण में यहां नियंत्रक केवल क्लासिक उत्पाद भंडार को लोड करेगा और उत्पाद को 5555 लोड करेगा। फिर उत्पाद को "अब आपको 4 स्टार रेट किया गया है" और सहेजें।
इस दृष्टिकोण में, नियंत्रक RateProduct कमांड बनाता है और उत्पाद 5555, सितारे 4 में भरता है। उदाहरण में यह यह भी भरता है कि रेटिंग कौन है।
इस समय, नियंत्रक "कमांड भेजता है" लिखने के लिए मॉडल। आपके पास यहां 2 विकल्प हैं: एक कमांड हैंडलर को आमंत्रित करें या इसे कतारबद्ध करें।
कहें कि आपके पास कतार नहीं है। फिर आप अपने नियंत्रक में CommandHandler प्राप्त करें (शायद निर्भरता इंजेक्शन द्वारा) और बस वहां कमांड रखें: h.Handle(c); जहां c रेटप्रोडक्ट कमांड है।
कहो आपके पास एक कतार है। फिर आप अपने नियंत्रक (शायद निर्भरता इंजेक्शन द्वारा) में कतार प्राप्त करते हैं और वहां केवल आदेश को संलग्न करते हैं: q.Queue(c);
इस अंतिम स्थिति में, कतार का श्रोता कमांड को कतार से बाहर ले जाएगा और इसके बजाय कमांड हैंडलर को कॉल करेगा।
एक थिर्स विकल्प (अनुशंसित) के रूप में, आपका नियंत्रक यह नहीं चुनता है कि कमांड को समकालिक रूप से संसाधित किया जा रहा है (हैंडलर प्राप्त करें) या अतुल्यकालिक रूप से (कतार प्राप्त करें) लेकिन एक "जेनेरिक दृष्टिकोण" का उपयोग करना चाहिए जो कमांड बस का उपयोग करना है रखे गए। मान लें कि कमांड बस बी है, तो आप बी करेंगे। भेजें (सी); जहां c रेटप्रोडक्ट कमांड है।
इस तीसरे दृष्टिकोण के साथ आप कमांड हैंडलर को बस के अंत में रखते हैं, और आप मिडलवेयर को "बस से कमांड निकालने और इसे कतार में रखने" के लिए कॉन्फ़िगर कर सकते हैं।

तो, जवाब देने के लिए:

मदद करने की उम्मीद है।
ज़ावी।

xmontero 18 जन॰ 2020

👍5

जैसा कि @xmontero ने उल्लेख किया है,

यदि आप कमांड को क्वेरी से अलग रखते हैं, तो आपने अपने आवेदन में CQRS डिज़ाइन पैटर्न लागू किया है। यह आपको लेखों में उल्लिखित CQRS के सभी लाभों को प्राप्त करने की दिशा में ले जाता है।

learnigility 24 जन॰ 2020

क्या यह पृष्ठ उपयोगी था?

0 / 5 - 0 रेटिंग्स

Architecture-center: ProductCommandHandler (CQRS) और ProductRepository (पारंपरिक आर्क) में क्या अंतर है?

दस्तावेज़ विवरण

सबसे उपयोगी टिप्पणी

सभी 5 टिप्पणियाँ

संबंधित मुद्दों