नेमस्पेस/समाधान संरचना

मैं इस तरह के एक सामान्य प्रश्न पूछने के लिए क्षमा चाहता हूं, लेकिन यह ऐसा कुछ है जो मेरे लिए चुनौतीपूर्ण साबित कर सकता है। मेरी टीम एक बड़ी परियोजना शुरू करने वाली है जो उम्मीद है कि वर्षों से विकसित होने वाले सभी यादृच्छिक एक-ऑफ कोडबेस को एक साथ खींचेंगी। यह देखते हुए कि इस परियोजना में कंपनी ("ग्राहक", "कर्मचारी"), छोटे कार्यों, छोटे कार्यों को नियंत्रित करने वाले बड़े कार्यों और उपयोगिता सेवाओं को मानकीकृत लॉजिकल इकाइयों को शामिल किया जाएगा, मैं संरचना करने के लिए सबसे अच्छा तरीका जानने के लिए संघर्ष कर रहा हूं नामस्थान और कोड संरचना।

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

  • मैं संदर्भों को आसान बनाने के लिए सबप्रोजेक्ट्स के साथ एक बड़े पैमाने पर समाधान पर बहस कर रहा हूं, लेकिन क्या इससे यह बहुत कमजोर हो जाएगा?
  • क्या मुझे विरासत एप्लिकेशन कार्यक्षमता को लपेटना चाहिए, या नामस्थान में पूरी तरह से अज्ञेयवादी छोड़ना चाहिए (उदाहरण के लिए, OurCRMProduct.Customer क्लास बनाम सामान्य <कोड> ग्राहक वर्ग बनाकर)?
  • क्या प्रत्येक सेवा/प्रोजेक्ट का अपना BAL और DAL होना चाहिए, या क्या यह पूरी तरह से अलग असेंबली होनी चाहिए जो सबकुछ संदर्भित करे?

मुझे ऐसी दूरगामी परियोजनाओं को व्यवस्थित करने का अनुभव नहीं है, केवल एक-ऑफ, इसलिए मैं किसी भी मार्गदर्शन की तलाश कर रहा हूं।

0
ro fr bn

6 उत्तर

मेरी सलाह, एक समान उपक्रम शुरू करने के बाद, नाम रिक्त स्थान पर परेशान नहीं है ..

बस कुछ महत्वपूर्ण ढीले दिशानिर्देशों के साथ विकास करना शुरू करें, क्योंकि आप शुरू करते हैं, आपकी परियोजना कार्बनिक है, और आप समय के साथ नाम रिक्त स्थान और कक्षाओं को पुनर्गठित करने के लिए करेंगे समाप्त कर देंगे।

अपनी परियोजना के बारे में बहुत ज्यादा बात करने में समय बर्बाद न करें। बस कर दो।

0
जोड़ा

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

सबसे पहले, जितनी ज्यादा हो सके परियोजनाओं की कुल संख्या को कम करें। जब आप दिन में बीस बार संकलित करते हैं, तो वह अतिरिक्त मिनट जोड़ता है।

यदि आपका ऐप एक्स्टेंसिबिलिटी के लिए डिज़ाइन किया गया है, तो डिज़ाइन बनाम कार्यान्वयन के आधार पर अपनी असेंबली को विभाजित करने पर विचार करें। सार्वजनिक असेंबली में अपने इंटरफेस और बेस क्लासेस रखें। इन वर्गों की अपनी कंपनी के कार्यान्वयन के लिए एक असेंबली बनाएं।

बड़े अनुप्रयोगों के लिए, अपना यूआई तर्क और व्यावसायिक तर्क अलग रखें।

अपना समाधान सरल बनाएं। अगर यह बहुत जटिल लग रहा है, तो शायद यह है। मिलाएं, कम करें।

0
जोड़ा

कई परियोजनाओं के साथ बड़े समाधान संकलित करने में काफी धीमे हो सकते हैं, लेकिन एक साथ प्रबंधित करना आसान है।

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

0
जोड़ा

मैंने हाल ही में काम पर सटीक अनुभव किया। बहुत सारे विज्ञापन-कोड जो संरचित और संगठित होने की आवश्यकता है।

पहली बार इसकी असली मुश्किल है, क्योंकि वहां बहुत कुछ है। मुझे लगता है कि मैं सबसे अच्छी सलाह दे सकता हूं कि शुक्रवार दोपहर को हवा में इसमें समय निवेश करें कुछ हफ्तों तक, मैं बस एक ऐप/कोड का हिस्सा चुनूंगा, जांचें कि क्या था वहां, इस बारे में सोचें कि हम जेनेरिक कैसे बना सकते हैं, इसे कॉपी करें, इसे नई लाइब्रेरी में डाल दें जहां भी मैंने सोचा था कि यह होना चाहिए। एक बार जब मेरे पास माइग्रेट किए गए एप्लिकेशन के भीतर सभी कोड थे, तो मैं सामान्य ढांचे से काम करने के लिए एप्लिकेशन को दोबारा करने पर काम करता हूं .. कभी-कभी ऐसी समस्याएं होती हैं जिन्हें ठीक करने की आवश्यकता होती है, लेकिन जब तक आपकी पूरी तरह से यह बहुत बड़ा नहीं होना चाहिए एक सौदा।

टुकड़ा टुकड़ा, यह करने का एकमात्र तरीका है।

संरचना के संदर्भ में, मैंने एमएस नेमस्पेसिंग की नकल करने की कोशिश की क्योंकि अधिकांश भाग इसकी सुंदर तार्किक (उदाहरण के लिए Company.Data , Company.Web , कंपनी .Web.UI और इसी तरह।

प्रमुख लाभों में से एक शायद कोड डुप्ली की मात्रा हटा दी गई है। हाँ ऐप्स में थोड़ा रिफैक्टरिंग की आवश्यकता थी, लेकिन कोड बेस बहुत दुबला है, और कई तरीकों से "स्मार्ट"।

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

लंबी पोस्ट के लिए खेद है .. यह तरह का जुआ है!

0
जोड़ा

हम .NET में असेंबली का नाम निम्नलिखित तरीके से कंपनी.प्रोजेक्ट.XXXX.YYYY जहां XXXX प्रोजेक्ट है और वाईवायवाई सबप्रोजेक्ट है, उदाहरण के लिए:

  • LCP.AdmCom.Common
  • LCP.AdmCom.BusinessObjects
  • LCP.AdmCom.Common.Dal

हम इसे Krzysztof Cwalina (लेखक), ब्रैड द्वारा फ्रेमवर्क डिज़ाइन दिशानिर्देश पुस्तक पुस्तक से लेते हैं। अब्राहम (लेखक)

0
जोड़ा

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

यहां एक लिंक है जो एक डीटीओ बताता है:

http://martinfowler.com/eaaCatalog/dataTransferObject.html

0
जोड़ा