क्या ऐसे आदेश बनाने का कोई मतलब है जो सिर्फ वस्तुओं को पकड़ते हैं? उदाहरण के लिए:

public class CreateCommand : IRequest
{
   SomeDTO SomeDTO { get; set; }
}

public class UpdateCommand : IRequest
{
   SomeDTO SomeDTO { get; set; }
}

या शायद ऐसा कुछ (व्युत्पन्न):

public class UpdateCommand : SomeDTO, IRequest
{
}

या आदेशों/अनुरोधों को स्वयं डीटीओ के रूप में माना जाना चाहिए? मैं भ्रमित हूं क्योंकि मैंने चीजों को करने के कई तरीके देखे हैं। सभी गुणों को कमांड/अनुरोध कक्षाओं में कॉपी करना एक अच्छी बात की तरह नहीं लगता है।

आप इसे अपनी परियोजनाओं में कैसे करते हैं?

क्या आप अपने आदेशों को सीधे अपने डोमेन मॉडल में मैप करते हैं या आप केवल डीटीओ पास करने के लिए कमांड का उपयोग करते हैं?

एमवीसी ढांचे का उपयोग करने के मामले में मेरे नियंत्रक कार्यों का इनपुट क्या होना चाहिए? क्या यह एक आदेश होना चाहिए, या क्या मुझे अपने क्रिया कार्यान्वयन के अंदर कमांड बनाना चाहिए और इसे भेजना चाहिए? (मुझे लगता है कि यह इस बात पर निर्भर करेगा कि मैं अपने आदेशों को कैसे मॉडल करता हूं)

2
Konrad 18 जून 2018, 14:16

2 जवाब

सबसे बढ़िया उत्तर

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

आदेश जो प्रक्रिया की सीमाओं को पार करते हैं वे संदेश हैं, जिसका अर्थ है byte[]s। यह वह बिट है जिसे रूप और शब्दार्थ दोनों में स्थिर होने की आवश्यकता है।

byte[] डोमेन अज्ञेयवादी है, और संदेश को "पार्सिंग" में कई अन्य डोमेन अज्ञेय मध्यवर्ती चरणों से गुजरना काफी सामान्य है

byte[] -> utf8
utf8 -> DOM
DOM -> Dictionary
...

लेकिन हम आम तौर पर एक डोमेन विशिष्ट अनुबंध की अभिव्यक्ति की ओर बढ़ रहे हैं।

उदाहरण के लिए देखें, मार्क सीमैन

सीमाओं पर, अनुप्रयोग वस्तु-उन्मुख नहीं हैं। एक डीटीओ एक वस्तु-उन्मुख भाषा में मैप किए गए डेटा के ऐसे टुकड़े का प्रतिनिधित्व है।

byte[] को क्वेरी करने के लिए सुविधाजनक रूप में ज़बरदस्ती करने के बाद, तब हम इस बारे में सोचना शुरू कर सकते हैं कि हम "ऑब्जेक्ट्स" को प्रारंभ करने के लिए उस डेटा का उपयोग करना चाहते हैं या नहीं।

दूसरा प्रश्न जो आप पूछ रहे हैं - क्या एक सामान्य मेटाडेटा "लिफाफे" के भीतर संदेश डेटा रखने का कोई मूल्य है। उस तरह का पैटर्न हर समय होता है - सबसे परिचित उदाहरण यह है कि एक HTTP पोस्ट एक संदेश-निकाय से जुड़े सामान्य शीर्षलेखों का एक समूह है।

डेटा और मेटाडेटा निश्चित रूप से अलग चिंताएं हैं; यह निश्चित रूप से आपके समाधान में उन्हें अलग रखने के लिए समझ में आता है।

मुझे लगता है कि डेटा संरचनाओं को इनहेरिट करने के बजाय कंपोजिट करना, अधिक रखरखाव योग्य विकल्प होने जा रहा है।

public class Envelope<Message> ....

एक उचित प्रारंभिक बिंदु हो सकता है।

2
VoiceOfUnreason 18 जून 2018, 15:30

आपको कमांड को "मौखिक वाक्य" के रूप में मानना ​​चाहिए जो आपके डोमेन को कुछ करने का निर्देश देता है। उदाहरण के लिए "अपडेट कमांड" आपके डोमेन को कुछ अपडेट करने का निर्देश देता है। कमांड के अंदर आपको कमांड की बारीकियों को शामिल करना चाहिए (आपके मामले में कि dto ठीक है) ...

हालांकि उन डीटीओ के साथ बहुत सावधान रहें। आप नहीं चाहते कि आपका डोमेन एमवीसी पर निर्भर हो बल्कि दूसरी तरफ। सुनिश्चित करें कि जिस असेंबली में डीटीओ रह रहा है वह डोमेन लॉजिक की तुलना में उच्च (एमवीसी की दिशा में) स्तर का नहीं है।

आपके एमवीसी में आपके पास केवल होना चाहिए:

  • निर्भरता इंजेक्शन सेटअप
  • नियंत्रक और दृश्य

नियंत्रकों में केवल विधि (http) पैरामीटर (विच असुरक्षित हैं) से डोमेन द्वारा आवश्यक डीटीओ में बदलने और डोमेन को कॉल करने के लिए आवश्यक कोड होना चाहिए।

कम से कम मैं तो यही कर रहा हूं।

0
John Verbiest 18 जून 2018, 15:20