2011-02-23 24 views
7

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

हालांकि यह बहुत अच्छा काम कर रहा है, अब मैं कई टेक्स्ट-आधारित फ़ाइल प्रारूपों से उपकरणों को आयात करने की सोच रहा हूं। इस कार्यप्रवाह पर विचार करें:

  1. निर्देशिका द्रष्टा सेवा देखता है एक नया उपकरण फ़ाइल
  2. जोड़ दिया गया है सेवा

अब उपकरणों फ़ाइल द्वारा वर्णित प्रस्तुत करने के लिए अपने आवेदन से एक आवेदन सेवा का उपयोग करता, आवेदन सेवा में निम्नलिखित नाम और हस्ताक्षर के साथ एक विधि हो सकती है: ApplianceService.Register(string fileContents)। मुझे लगता है कि निर्देशिका वॉचर सेवा इस सेवा विधि का उपयोग करेगी और इसे फ़ाइल की पूरी सामग्री पास कर देगी। आवेदन सेवा तब पार्सिंग समन्वयित करेगी। फ़ाइल की सामग्री को पार्स करना और इसे पूर्ण उपकरणों की इकाइयों में बदलने से कई कदम शामिल हैं। अब, मेरा सवाल है:

प्रश्न: क्या यह सही है, या पार्सिंग तर्क निर्देशिका वॉचर सेवा के भीतर रहना चाहिए? प्रत्येक प्रकार का फ़ाइल प्रारूप डोमेन का एक हिस्सा है, लेकिन फिर, यह नहीं है। फ़ाइलों को किसी भी प्रारूप से इकाइयों में पार्स किए जाने के बाद, इकाई कभी नहीं जान पाएगी कि इसे एक बार प्रारूप का उपयोग करके दर्शाया गया था। यदि पार्सिंग तर्क वॉचर सेवा के भीतर रहना चाहिए, तो मैं डेटा ट्रांसफर ऑब्जेक्ट्स के रूप में पंजीकरण सेवाओं में नए उपकरण पास कर दूंगा।

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

इस पर कोई भी विचार बहुत स्वागत है।

उत्तर

1

एसआरपी (एकल उत्तरदायित्व सिद्धांत) के अनुसार, आपको अपना विचार रखना चाहिए। Directory Watcher service जो करना चाहिए वह करना चाहिए - निर्देशिका में नई फ़ाइलों के लिए देखें और उन्हें दूसरी सेवा, यानी Appliance Service पर पास करें जो उन्हें डेटा स्थानांतरण ऑब्जेक्ट्स में परिवर्तित करता है। अब आप अपने डेटा ट्रांसफर ऑब्जेक्ट्स को एप्लिकेशन में सबमिट करने के लिए अपने web services का उपयोग कर सकते हैं।

मैं Appliance Service के लिए एक इंटरफ़ेस बनाउंगा, कम से कम एक विधि Convert() नामक एक विधि के साथ। Appliance Parsing Service कक्षा इंटरफ़ेस को कार्यान्वित कर सकती है। आइए बाद में कहें कि आपके पास उपकरणों के लिए एक अलग स्रोत (एसक्यूएल) है। आप एक और कक्षा Appliance SQL Service लिख सकते हैं जो Appliance Service लागू करता है।

1

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

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

जहां मेरा सिर थोड़ा सा हो गया (जो शायद आपके जैसा ही है?) यह था कि यह वास्तव में एप्लिकेशन सेवा की ज़िम्मेदारी नहीं है जो आपकी विभिन्न डोमेन इकाइयों का समन्वय करता है। हालांकि, मुझे लगता है कि एप्लिकेशन सेवा कुछ प्रकार के बिल्डर पैटर्न का लाभ उठाने का सही स्थान है, प्रत्येक फ़ाइल को पार्स करने की प्रत्येक विधि के ब्योरे को दूर करने के लिए, लेकिन डोमेन में एक स्पष्ट स्थान भी बना रहा है जहां यह पार्सिंग समन्वयित है।

प्रत्येक फ़ाइल प्रारूप डोमेन का हिस्सा होने के लिए या नहीं। मैं कहूंगा कि वे हैं - आप कल्पना कर सकते हैं कि उन सभी को सर्वव्यापी भाषा के हिस्से के रूप में व्यक्त किया जा रहा है, जिसमें विभिन्न डोमेन विशेषज्ञ एक्स फ़ाइल प्रारूप या वाई फ़ाइल प्रारूप और व्यक्त किए गए डेटा के quirks के बारे में बात कर रहे हैं। उस प्रकार का पार्सिंग और मैपिंग बहुत पहले श्रेणी डोमेन तर्क है।

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

+0

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

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