वास्तुकला प्रश्न

Question

पिछली पोस्ट (Architecture: simple CQS) के परिणामस्वरूप मैं सोच रहा था कि मैं एक साधारण प्रणाली कैसे बना सकता हूं जो बाद में विस्तारित करने के लिए पर्याप्त लचीला है।

दूसरे शब्दों में: मुझे अब एक पूर्ण उड़ाए गए सीक्यूआरएस की आवश्यकता नहीं दिखाई दे रही है, लेकिन यदि आवश्यक हो तो मैं इसे बाद में विकसित करना आसान बनाना चाहता हूं।

तो मैं पूछताछ से कमांडिंग को अलग करने के बारे में सोच रहा था, लेकिन दोनों एक ही डेटाबेस पर आधारित थे।

क्वेरी भाग आसान होगा: डेटा के लिए पूछताछ करना आसान है कि विचारों के आधार पर एक डब्ल्यूसीएफ डेटा सेवा। वहां कुछ भी खास नहीं है।

कमांड हिस्सा कुछ और कठिन है, और यहां एक विचार है: आदेश निश्चित रूप से एक असीमित तरीके से निष्पादित किए जाते हैं, इसलिए वे परिणाम नहीं लौटाते हैं। लेकिन, मेरे एएसपी.नेट एमवीसी साइट के नियंत्रकों को अक्सर कमांड से प्रतिक्रिया की आवश्यकता होती है (उदाहरण के लिए यदि किसी सदस्य का पंजीकरण सफल हुआ या नहीं)। इसलिए यदि नियंत्रक कमांड भेजता है, तो यह एक लेनदेन आईडी (एक guid) भी उत्पन्न करता है जो कमांड गुणों के साथ पास हो जाता है। कमांड सेवा इस कमांड को प्राप्त करती है, इसे डेटाबेस में 'प्रोसेसिंग' के साथ डेटाबेस में लेनदेन तालिका में डालती है, और इसे निष्पादित किया जाता है (डीडीडी सिद्धांतों का उपयोग करके)। निष्पादन के बाद, लेनदेन तालिका अद्यतन की जाती है, ताकि राज्य 'पूर्ण' या 'असफल' हो और अन्य प्राथमिक जानकारी जैसे उत्पन्न प्राथमिक कुंजी हो।

इस बीच साइट इस लेनदेन की स्थिति के लिए क्वेरी के लिए क्वेरी सेवा का उपयोग कर रही है, जब तक कि इसे 'पूरा' या 'असफल' न हो जाए, और फिर यह इस परिणाम के आधार पर अपना काम जारी रख सके। यदि लेनदेन तालिका मतदान की जाती है और परिणाम 'पूरा' या 'विफल' होता है, तो प्रविष्टि हटा दी जाती है।

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

ज्यादातर मामलों में इस मतदान तंत्र की शायद आवश्यकता नहीं है, लेकिन यदि आवश्यक हो तो संभव है। और इंटरफेस को सीक्यूएस के साथ दिमाग में डिजाइन किया गया है, इसलिए भविष्य के लिए खुला है।

क्या आप इस दृष्टिकोण में किसी भी त्रुटि के बारे में सोचते हैं? अन्य विचार या सुझाव?

धन्यवाद!

लूद

Answer 1

मुझे लगता है कि आप अपने दृष्टिकोण के साथ एक पूर्ण CQRS व्यवस्था करने के लिए बहुत करीब हैं।

मेरे पास एक ऐसी साइट है जिसे मैं आप जो वर्णन कर रहा हूं उसके समान कुछ करता था। मेरी साइट, braincredits.com, सीक्यूआरएस का उपयोग करके आर्किटेक्टेड है, और सभी आदेश प्रकृति में async हैं। इसलिए, नतीजतन, जब मैं एक प्रविष्टि बनाता हूं, तो को प्रसंस्करण के लिए सबमिट किए गए आदेश के अलावा उपयोगकर्ता को वास्तव में कोई प्रतिक्रिया नहीं है (यह संसाधित नहीं है)।

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

आप किस बारे में बात कर रहे हैं अंततः स्थिरता है - कि उपयोगकर्ता द्वारा देखे जा रहे एप्लिकेशन की स्थिति अंततः सिस्टम डेटा (रिकॉर्ड की प्रणाली) के अनुरूप होगी। यह अवधारणा सीक्यूआरएस के लिए बहुत महत्वपूर्ण है, और, मेरी राय में, बहुत समझ में आता है।जैसे ही आप किसी सिस्टम में डेटा पुनर्प्राप्त करेंगे (चाहे वह एक सीक्यूआरएस आधारित है या नहीं), डेटा पुराना है। लेकिन यदि आप इसे मानते हैं और मानते हैं कि ग्राहक अंततः सुसंगत रहेगा, तो आपका दृष्टिकोण समझ में आता है और आप इसके लिए अपने यूआई को भी खाते में डिज़ाइन कर सकते हैं और इसका लाभ उठा सकते हैं।

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

क्वेरी पक्ष के लिए डब्ल्यूसीएफ डेटा सेवा परत एक अच्छा विचार है - बस सुनिश्चित करें कि यह केवल पढ़ने-सक्षम है (जो मुझे यकीन है कि आपने किया है)।

इसके अलावा, ऐसा लगता है कि आप अच्छी शुरूआत में हैं।

मुझे उम्मीद है कि इससे मदद मिलती है। सौभाग्य!