अद्यतन सेवा के साथ डीटीओ के उपयोग से पूछताछ और अद्यतन

Question

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

एक बात जो मैं सोच रहा हूं वह है जब मैं बनाना चाहता हूं, उदाहरण के लिए, अंतर्निहित सेवा के लिए एक गेटवे गेटवे। उदाहरण के प्रयोजनों के लिए, मान लीजिए कि मैं निम्न विधियों के साथ एक टास्क वस्तु है,

• ChangeDueDate(DateTime date)
• ChangeDescription(string description)
• AddTags(params string[] tags)
• Complete()

अब स्पष्ट रूप से मैं उदाहरण वैरिएबल नहीं होगा इस ऑब्जेक्ट के अंदर राज्य और घटनाओं को नियंत्रित करने के लिए जो प्रासंगिक विधियों का आह्वान किया जाएगा, निकाल दिया जाएगा।

1. मेक RPC शैली यूआरएल उदहारण के लिए:

   बाकी सेवा, जिस तरह से मैं इसे देखने के लिए वापस जा रहे हैं वहाँ 3 विकल्प हैं http://127.0.0.1/api/tasks/{taskid}/changeduedate

2. कई आदेशों के लिए अनुमति दें एक भी endpoint जैसे के लिए भेजा जाना:
   • यूआरएल: http://127.0.0.1/api/tasks/{taskid}/commands
   • यह आदेशों की एक सूची को स्वीकार करेंगे तो मैं एक ही अनुरोध में निम्नलिखित भेज सकता है:
     • ChangeDueDate आदेश
     • ChangeDescription आदेश
3. वास्तव में एक RESTful क्रिया उपलब्ध कराएं और मैं प्रासंगिक घटनाओं में अनुवाद की आवश्यकता जैसे एक डीटीओ से और बदले में परिवर्तन निकालने के लिए डोमेन तर्क बनाने के लिए:
   • यूआरएल: http://127.0.0.1/api/tasks/{taskid}
   • मैं करने के लिए रखा क्रिया का प्रयोग करेंगे एक काम
   • प्राप्त होने के बाद मैं एक विधि शायद कहा जाता है के माध्यम से वास्तविक कार्य डोमेन ऑब्जेक्ट को डीटीओ दे सकता है की एक डीटीओ प्रतिनिधित्व, UpdateStateFromDto
   • भेजने यह तो डीटीओ का विश्लेषण और मतभेदों को खोजने के लिए अपने क्षेत्र के लिए मिलान गुण तुलना होगा और प्रासंगिक ई हो सकता है वेंट जिसे किसी विशेष संपत्ति के साथ अंतर मिलने पर निकाल दिया जाना चाहिए।

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

पहला विकल्प निश्चित रूप से स्पष्ट होगा लेकिन परिणामस्वरूप कई व्यवहार किए जाने पर 1 से अधिक अनुरोध होंगे।

तीसरा विकल्प होने के लिए बुरा नहीं लग रहा है, लेकिन मुझे लगता है कि यह एक साफ कार्यान्वयन है कि विभिन्न संपत्ति प्रकार के लिए जिम्मेदार होती है, घोंसला बनाने आदि के साथ आने के लिए कुछ thougth की आवश्यकता होगी ...

इस में आपकी मदद के लिए धन्यवाद , वास्तव में विश्लेषण पक्षाघात के माध्यम से मेरे सिर झुकना। दूसरों को लगता है कि विकल्पों से सबसे अच्छा तरीका क्या होगा या क्या मुझे एक चाल याद आ रही है, इस बारे में कुछ सलाह चाहिए।

Answer 1

मैं विकल्प 1. कहेंगे आप अपनी सेवा RESTful होना चाहते हैं तो विकल्प 2 एक विकल्प नहीं है, तो आप सुरंग अनुरोध होगी।

POST /api/tasks/{taskid}/changeduedate लागू करने के लिए आसान है, लेकिन आप भी PUT /api/tasks/{taskid}/duedate कर सकते हैं।

यदि आप समूह में कई प्रक्रियाओं, जैसे करना चाहते नियंत्रक संसाधनों बना सकते हैं POST /api/tasks/{taskid}/doThisAndThat, मैं ग्राहक उपयोग प्रतिमानों के आधार पर करना होगा कि।

तुम सच में एक अनुरोध में "व्यवहार" के किसी भी नंबर पर कॉल करने की क्षमता प्रदान करने के लिए की जरूरत है? (ऑर्डर मायने रखता है?)

यदि आप विकल्प 3 के साथ जाना चाहते हैं तो मैं PATCH /api/tasks/{taskid} का उपयोग करूंगा, इस तरह क्लाइंट को अनुरोध में सभी सदस्यों को शामिल करने की आवश्यकता नहीं है, केवल वे जिन्हें बदलने की आवश्यकता है।

Answer 2

चलिए एक शब्द परिप्रेक्ष्य से operation = command or query परिभाषित करते हैं, उदाहरण के लिए ChangeTaskDueDate(int taskId, DateTime date) एक ऑपरेशन है।

तक बाकी आप संसाधन संचालन और विधि जोड़े मैप कर सकते हैं। इसलिए एक ऑपरेशन को कॉल करना मतलब संसाधन पर एक विधि लागू करना है। संसाधनों को यूआरआई द्वारा पहचाना जाता है और संज्ञाओं, जैसे कार्य या तारीख इत्यादि द्वारा वर्णित हैं ... विधियों को HTTP मानक में परिभाषित किया गया है और क्रियाएं हैं, जैसे कि प्राप्त, पोस्ट, पुट इत्यादि ... यूआरआई संरचना वास्तव में नहीं है आरईएसटी क्लाइंट के लिए कुछ भी मतलब है, क्योंकि ग्राहक मशीन पठनीय सामान से चिंतित है, लेकिन डेवलपर्स के लिए राउटर, लिंक पीढ़ी को कार्यान्वित करना आसान बनाता है, और आप यह सत्यापित करने के लिए इसका उपयोग कर सकते हैं कि आपने यूआरआई को संसाधनों के लिए बाध्य किया है या नहीं, आरपीसी करता है।
तो हमारे वर्तमान उदाहरण ChangeTaskDueDate(int taskId, DateTime date) द्वारा क्रिया change होगी और संज्ञा task, due-date हैं। तो आप निम्न समाधान का उपयोग कर सकते हैं:

• PUT /api{/tasks,id}/due-date "2014-12-20 00:00:00" या आप
• PATCH /api{/tasks,id} {"dueDate": "2014-12-20 00:00:00"} उपयोग कर सकते हैं।

अंतर यह है कि पैच आंशिक अपडेट के लिए है और यह आवश्यक idempotent नहीं है।

अब यह एक बहुत ही आसान उदाहरण था, क्योंकि यह सादा सीआरयूडी है। गैर सीआरयूडी परिचालनों से आपको उचित क्रियाएं मिलनी होंगी और शायद एक नया संसाधन परिभाषित करना होगा। यही कारण है कि आप केवल सीआरयूडी परिचालनों द्वारा संस्थाओं को संसाधनों को मैप कर सकते हैं।

1. मेक RPC शैली यूआरएल उदहारण के लिए:

   बाकी सेवा, जिस तरह से मैं इसे देखने के लिए वापस जा रहे हैं वहाँ 3 विकल्प हैं

   • यूआरएल:: http://example.com/api/tasks/ {taskid}/changeduedate
   • कई आदेशों के लिए अनुमति दें एक भी endpoint जैसे के लिए भेजा जाना http://example.com/api/tasks/ {taskid}/
   • आदेशों यह आदेशों की एक सूची को स्वीकार करेंगे तो मैं निम्नलिखित भेज सकता है
     • ChangeDueDate आदेश
     • ChangeDescription आदेश

: एक ही अनुरोध में
2. वास्तव में एक शोकहारा क्रिया उपलब्ध कराएं और मैं एक डीटीओ से और बदले में प्रासंगिक घटनाओं की आवश्यकता जैसे में अनुवाद परिवर्तन निकालने के लिए डोमेन तर्क बनाने के लिए:
   • यूआरएल: http://example.com/api/tasks/ {taskid}
   • मैं PUT क्रिया का प्रयोग करेंगे एक काम
   • प्राप्त होने के बाद मैं एक विधि शायद कहा जाता है के माध्यम से वास्तविक कार्य डोमेन ऑब्जेक्ट को डीटीओ दे सकता है की एक डीटीओ प्रतिनिधित्व, UpdateStateFromDto
   • भेजने के लिए यह तो डीटीओ का विश्लेषण करने और खोजने के लिए अपने क्षेत्र के लिए मिलान गुण तुलना होगा अंतर और प्रासंगिक घटना जो नींद हो सकती है जब के साथ कोई अंतर मिलता है तो उसे निकाला जा सकता है।

1. यूआरआई संरचना कुछ भी मतलब नहीं है। हम अर्थशास्त्र के बारे में बात कर सकते हैं, लेकिन आरईएसटी आरपीसी से बहुत अलग है। It has some very specific constraints, which you have to read before doing anything.

2. यह आपके पहले उत्तर के समान समस्या है। आपको HTTP विधियों और यूआरआई में संचालन मैप करना होगा। वे संदेश निकाय में यात्रा नहीं कर सकते हैं।

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