एसओए डिज़ाइन में सीआरयूडी ऑपरेशन इतने खराब क्यों हैं?

Question

मैंने अभी MSDN by John Evdemon पर एक लेख पढ़ना समाप्त कर दिया है। वह सीआरयूडी इंटरफेस को ढकता है और इसे एक विरोधी पैटर्न कहते हैं।

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

या मैं यहां क्या खो रहा हूं?

Answer 1

CRUD इंटरफेस के साथ एक समान प्रश्न मिले वितरित प्रणाली/एसओए परिदृश्य में बचा जाना चाहिए, क्योंकि वे बहुत बातूनी होते हैं। लेकिन इसका मतलब यह नहीं होना चाहिए। जब आपके पास कुछ क्लाइंट क्रियाएं होती हैं जिन्हें आपकी सेवा में एक से अधिक कॉल की आवश्यकता होती है तो आप जानते हैं कि आपको सीआरयूडी दृष्टिकोण छोड़ना चाहिए और नए सर्विस ऑपरेशन बनाना चाहिए जो उन कॉल को सिंगल कॉल में एग्रीगेट करेगा। वितरित प्रणाली को डिज़ाइन करते समय आपको हमेशा कॉल की संख्या कम से कम कम करनी चाहिए क्योंकि नेटवर्क कॉल बहुत समय ले रहा है।

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

आप एक ऐसी सेवा में उजागर डेटा का उपयोग के बारे में के रूप में CRUD इंटरफ़ेस के बारे में सोच सकते हैं। कभी-कभी आप वास्तव में यह चाहते हैं। लेकिन एसओए और वितरित सिस्टम आर्किटेक्चर में आप आमतौर पर व्यावसायिक कार्यक्षमता का पर्दाफाश कर रहे हैं जो पहले से ही डेटा एक्सेस को लपेटता है और अधिक जटिल संचालन प्रदान करता है (जो कई डेटा एक्सेस ऑपरेशंस को नियंत्रित करता है)।

उदाहरण:

CRUD एक्स व्यापार तर्क इंटरफ़ेस। मान लीजिए कि आप Invoices के साथ काम कर रहे हैं। प्रत्येक चालान में InvoiceHeader और एक या अधिक InvoiceLine शामिल होते हैं। यदि आप इनवॉइस के लिए सीआरयूडी इंटरफ़ेस का उपयोग करते हैं तो आप InvoiceHeader बनाने के लिए पहले CreateInvoiceHeader ऑपरेशन को कॉल करेंगे और फिर AddInvoiceLine ऑपरेशंस को सभी InvoiceLines जोड़ने के लिए ऑपरेशन करेंगे - यह निम्न स्तर सीआरयूडी दृष्टिकोण है। लेकिन यदि आप सेवा पक्ष पर व्यवसाय तर्क लागू करते हैं तो आप एकल CreateInvoice पर कॉल करेंगे और आवश्यकतानुसार बनाने और जोड़ने के लिए एक जटिल ऑब्जेक्ट ग्राफ़ (सभी पंक्तियों के साथ शीर्षलेख) को पास करेंगे। Create विधि कुछ वर्कफ़्लो इत्यादि जैसे अन्य व्यावसायिक संचालन भी कर सकती है। यह सामान्य एसओए और वितरित सिस्टम दृष्टिकोण है।

Answer 2

RESTfull web services जो हाल ही में लोकप्रियता प्राप्त कर रहे हैं, गलत श्री जॉन एवडमन की पोस्ट साबित कर रहे हैं।

Answer 3

मुझे लगता है कि उन्होंने उद्देश्य पर सबसे खराब संभव इंटरफ़ेस डिज़ाइन किया है और यह वास्तव में एक CRUD इंटरफ़ेस नहीं है।

<WebMethod()> _ 
Public Function MoveNext() As Boolean 
End Function 

<WebMethod()> _ 
Public Function Current() As Object 
End Function 

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

अद्यतन:

एक बहुत अच्छा answer :)

Answer 4

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

उदाहरण के लिए मान लें कि हमारे पास एक ब्लॉग एपीआई है। मान लें कि हम उपयोगकर्ताओं को पोस्ट लिखने, छवियों को जोड़ने और हमारे बाहरी एप्लिकेशन की एक स्क्रीन पर टिप्पणियां रखने की क्षमता देते हैं। SOA के जॉन की दृष्टि में वह शायद सुझाव है कि हम एक कॉल उपयोग करने के लिए इन बातों के सभी करने के लिए तो यह कम बातूनी और ऐसा ऐसा किया जाएगा हमारे एपीआई का निर्माण ... इसलिए:

{ 
    "post_title": "New Post", 
    "post_content": "Some Stuff....", 
    "comments": [{ 
    "comment": "This is right on!", 
    "userId": 101 
    }, { 
    "comment": "I agree.", 
    "userId": 105 
    }], 
    "images": [{ 
    "imgURL": "http://some.img.com/1" 
    }, { 
    "imgURL": "http://some.img.com/2" 
    }] 
} 

अब स्पष्ट रूप से कर रहे हैं तीन अलग-अलग डेटा ऑब्जेक्ट जिन्हें अलग से अलग करने की आवश्यकता है: पोस्ट, टिप्पणियां और छवियां। डेटा स्टोर के परिप्रेक्ष्य से पोस्ट POSTS तालिका में टिप्पणियाँ तालिका और छवियों को IMAGES तालिका में टिप्पणियों पर जाता है। इसलिए यदि हम एसओए के किरायेदारों के बाद हमारी सेवा बनाते हैं क्योंकि जॉन उनका वर्णन करता है तो हम अपने ऑब्जेक्ट के साथ अपना एक कॉल करते हैं और यह उन सेवाओं को जाता है जो पोस्ट बनाने का प्रयास करते हैं, उदाहरण के लिए, केवल ठीक काम करता है तो यह बनाने का प्रयास करता है टिप्पणियां जो ठीक काम करती हैं लेकिन जब हम छवियों पर पहुंचते हैं तो सेवा को पता चलता है कि छवि यूआरएल में से एक दोषपूर्ण है। तो हमारी सेवा विफलता देता है? भले ही 3 अन्य हिस्सों को अब हमारे डेटा स्टोर में सफलतापूर्वक संग्रहीत किया गया हो? क्या हम वापस जाते हैं और सफलतापूर्वक निष्पादित सभी भागों को पूर्ववत करते हैं? क्या होगा यदि डेटा स्टोर ने पहले से ही बदलाव किए हैं, और हम इसे वापस रोल नहीं कर सकते हैं?

इस तथ्य के साथ युगल करें कि अगर हम इसे "अधिक चतुर" बनाते हैं और उन्हें व्यक्तिगत रूप से प्रस्तुत करते हैं तो हम अब सेवा के किसी भी हिस्से को फिर से लिखने के बिना अन्य सेवाओं में उन सेवाओं का पुन: उपयोग कर सकते हैं।

समेकित सेवाओं का बुरा हिस्सा यह है कि आपको इस विचार पर बेचा जा रहा है कि सेवा कभी विफल नहीं होनी चाहिए ... जो हास्यास्पद है। हमेशा एक बढ़िया मामला होगा जहां कुछ असफल हो जाएगा और सबकुछ एक सेवा में समेकित करके आपने अपनी जटिलता में वृद्धि की है और वास्तव में विफल होने की आपकी क्षमता में वृद्धि की है।

मैं एसओए के इस संस्करण की तुलना उन कमियों के साथ करूंगा जिन्हें हमने ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग में भगवान ऑब्जेक्ट्स बनाने में पहले से ही महसूस किया है। https://en.wikipedia.org/wiki/God_object

हम इससे बेहतर जानते हैं तो हम इसे क्यों रीहा कर रहे हैं? समेकित या भगवान सेवा भगवान वस्तुओं की तरह एक बुरा विचार है। मैं कहता हूं कि एक काम करने के लिए अपनी सेवाएं बनाएं और जितना उपयोग कर सकते हैं उतने उपयोग के लिए इसे अच्छी तरह से करें और आपकी सेवा अच्छी होगी।