2010-04-07 25 views
11

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

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

मैं आर्किटेक्चर रीडिज़ाइन के विचार के लिए खुला हूं, लेकिन केवल अंतिम उपाय के रूप में। तो मेरे पास एक साझा हेल्पर लाइब्रेरी कैसे हो सकती है जो व्यावसायिक ऑब्जेक्ट्स तक पहुंच सकती है, व्यवसाय की वस्तुएं अभी भी साझा हेल्पर लाइब्रेरी तक पहुंच सकती हैं?

+2

स्पष्ट सवाल यह है कि साझा लाइब्रेरी को व्यावसायिक ऑब्जेक्ट्स तक पहुंच की आवश्यकता क्यों है? यदि आप इसका उत्तर दे सकते हैं, तो आपके पास समाधान होगा। – Aaronaught

+0

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

+2

यही कारण है कि मैं लाइब्रेरी का वर्णन करने के लिए "साझा" जैसी अस्पष्ट शर्तों का कभी भी उपयोग नहीं करता हूं। वास्तव में यह क्या करता है? जिसे आप साझा लाइब्रेरी कहते हैं, स्पष्ट रूप से बहुत अधिक जिम्मेदारियां हैं, और शायद व्यापार ऑब्जेक्ट लाइब्रेरी भी करता है। आम तौर पर, इन समाधानों को वास्तव में * स्वतंत्र * कक्षाओं/इंटरफेस को अपनी पुस्तकालय में डालकर हल किया जाता है। – Aaronaught

उत्तर

17

आप केवल मूल्य वस्तुओं (कोई तर्क नहीं) के लिए अलग प्रोजेक्ट बना सकते हैं और इंटरफेस बना सकते हैं।

अपने साझा लाइब्रेरी कक्षाएं इंटरफेस लागू है, और व्यापार पुस्तकालय इंटरफेस पर निर्भर करते हैं (मैं और अधिक परीक्षण योग्य सुनना करते हैं और यहाँ कोड decoupled? की कोई बात नहीं आप साझा लाइब्रेरी पर निर्भरता को निकालना उल्लेख)।

आदर्श रूप से, आपके पास ऐसी व्यावसायिक वस्तुएं हो सकती हैं जिन पर आपकी साझा लाइब्रेरी इस अतिरिक्त परियोजना पर भी निर्भर करती है। यदि व्यवसाय की वस्तुएं बहुत जटिल हैं, तो आप उन्हें इंटरफेस में भी बदल सकते हैं।

आप दोनों परियोजनाओं के लिए एक दूसरे पर निर्भर करता है नहीं होगा, लेकिन केवल केवल "डमी" वस्तुओं के साथ एक अन्य परियोजना (कोई तर्क) पर:

व्यापार ---> इंटरफेस और मूल्य वस्तुओं < --- साझा लाइब्रेरी

अब उन decoupled =)

+0

यह उत्तर है। – Strelok

+0

यदि आप अभी तक आर्किटेक्ट को दूर करने के लिए जा रहे हैं तो निर्भरता क्यों खत्म लाइन से 5 फीट कम हो और न केवल आर्किटेक्ट को दूर कर दें? उस समय आपके पास कोई और कोड नहीं होगा जो व्यवसाय संस्थाओं पर निर्भर है और साझा परियोजना में मूल रूप से साझा कोड छोड़ सकता है। मेरा जवाब कौन सा होगा। –

+0

@ क्रिस यह एक बड़ा बदलाव नहीं है। इसके लिए कुछ रिफैक्टरिंग की आवश्यकता होगी, लेकिन कोई बड़ी रीडिज़ाइन या सामान को फिर से हटाने की आवश्यकता नहीं है। –

0

एक समाधान के बीच एक मुखौटा पैटर्न रखना होगा। यहां आप साझा लाइब्रेरी से अपनी व्यावसायिक ऑब्जेक्ट्स तक सीधी पहुंच/निर्भरता से बचेंगे। इसके बजाय, आप एक परत का उपयोग करेंगे जो आपके lib और BOs के बीच एक मुखौटा के रूप में कार्य करता है। इस तरह आप अपने साझा पुस्तकालयों को साफ और decoupled पैक कर सकते हैं।

+1

मैं कंक्रीट पैटर्न नाम निर्दिष्ट किए बिना 'अबास्ट्रक्शन' कहूंगा (यह आसानी से एडाप्टर, रणनीति, पुल हो सकता है) क्योंकि डिजाइन पैटर्न मुख्य उद्देश्य इस तरह के मुद्दों को हल करने में नहीं है। –

3

जब भी आपके पास "साझा" लाइब्रेरी है तो आपको बिल्कुल अपनी व्यावसायिक इकाई प्रोजेक्ट का संदर्भ नहीं देना चाहिए। ऐसा करने से आप इस मुद्दे को होने के कारण स्पष्ट रूप से देखेंगे।

इसका समाधान साझा लाइब्रेरी से सभी व्यावसायिक इकाई निर्भर कोड को हटा देता है और या तो उस सहायक कोड की आवश्यकता को फिर से शुरू कर देता है या उस व्यावसायिक इकाई प्रोजेक्ट के अंदर हेल्पर कोड रखता है।

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