एन-टियर आर्किटेक्चर में डेटाबेस-कार्यक्षमता ऑब्जेक्ट्स को कार्यान्वित करना?

Question

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

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

हमारे पदानुक्रम इस तरह दिखता है: आम> मॉडल> ​​दाल> बाल

यहाँ स्तरों के बारे में अधिक विस्तार से बताया। ध्यान रखें, मैंने इसे विरासत में प्राप्त किया है: आम सभी "उपयोगिता" कार्यों के लिए ज़िम्मेदार है जो एप्लिकेशन में कई स्थानों का उपयोग किया जाता है, कॉन्फ़िगरेशन सेटिंग्स तक पहुंचने जैसी चीजें, तारों को पार्सिंग, गैर-व्यावसायिक संबंधित कार्यक्षमता।

मॉडल व्यावसायिक वस्तुएं हैं, कुछ लोग डेटा ट्रांसफर ऑब्जेक्ट्स, गेटर्स और सेटर्स के संग्रह कहलाते हैं। मैंने इस परत पर कुछ "स्मारक" जोड़े हैं, लेकिन उस ऑब्जेक्ट के लिए केवल व्यावसायिक नियम आंतरिक हैं, जैसे "एक आइटम का नाम अल्फान्यूमेरिक कैरेक्टर से शुरू होना चाहिए।"

डीएएल डेटा एक्सेस लेयर है, सिद्धांत रूप में, यहां जो भी होता है वह मॉडल ऑब्जेक्ट्स डेटाबेस में और बाहर ले जाया जाता है।

बीएएल बिजनेस लेयर है; सिद्धांत रूप में, वस्तुओं के संपर्क को नियंत्रित करने वाले व्यवसाय नियम लागू किए जाते हैं (यानी "एक फॉर्म में कम से कम दो आइटम होना चाहिए।")।

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

क्या किसी और ने किसी व्यापारिक वस्तु से निपटाया है जिसका उद्देश्य डेटाबेस के साथ बातचीत करना है, और आप अपने एन-स्तरीय आर्किटेक्चर में इसे कैसे व्यवस्थित करते हैं?

लिंक से एसक्यूएल का उपयोग करने के लिए मुझे बताए जाने से पहले, बहुत धन्यवाद। यह एक तकनीकी प्रश्न नहीं है (मैं यह कैसे कर सकता हूं), यह एक डिज़ाइन प्रश्न है (मुझे यह कैसे करना चाहिए)।

मुझे लगता है कि एक स्टैक एक्सचेंज साइट भाषा-स्वतंत्र डिजाइन प्रश्नों के इस प्रकार पर केंद्रित है, इसलिए मैं इसे कॉपी करने जा रहा हूं।

Answer 1

से बहुत कुछ सीखा।

मैंने प्रोग्रामर को इसे पार किया, जहां मुझे लगता है कि इस तरह का प्रश्न वास्तव में संबंधित हो सकता है, और कुछ उपयोगी विचार प्राप्त हुए। यदि आप रुचि रखते हैं, तो धागा यहां है: Programmers thread on this issue। माना जाता है कि, जब मैंने वहां पोस्ट किया था, तो मैंने अपने स्वयं के शोध के आधार पर निर्भरता इंजेक्शन का "संकेत" जोड़ा, इसलिए समस्या स्पष्ट हो सकती है।

यह एक शानदार और उपयोगी समुदाय है, जो मैं में भाग लेने के इतना गर्व कर रहा हूँ है।

Answer 2

यदि आपके मॉडल कक्षाएं आपके डीटीओ हैं (कुछ डेटा संरचनाओं या डेटा प्रकारों को कॉल कर सकती हैं), तो उन्हें (शायद) अपनी अन्य परतों को "पार" रखना चाहिए और उन सभी के लिए जाना जाना चाहिए।

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

Answer 3

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

क्या किसी और ने किसी व्यापारिक वस्तु से निपटाया है जिसका उद्देश्य डेटाबेस के साथ बातचीत करना है, और आप अपने एन-स्तरीय आर्किटेक्चर में इसे कैसे व्यवस्थित करते हैं?

तरह से अपनी परियोजनाओं को संरचित कर रहे हैं, यह एक परत के तार्किक जिम्मेदारियों की तरह लगता है होगा:

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

आप इसे विभिन्न तकनीकों के साथ प्राप्त कर सकते हैं और उसी तकनीक का उपयोग करके भी आपका सटीक कार्यान्वयन इस बात पर निर्भर करता है कि आप कैसे काम करते हैं। लिंक 2 एसक्यूएल, या बॉक्स के बाहर इकाई फ्रेमवर्क जैसी कुछ आपके मॉडल और आपके डीएएल के बीच की रेखाओं को धुंधला कर देगी; वे एक ही परियोजना में दोनों को परिभाषित करना चाहते हैं। हालांकि, इकाई फ्रेमवर्क अधिक लचीला है और कुछ कामों के साथ आप इकाई मॉडल और "संदर्भ" (इकाई फ्रेमवर्क अवधि का उपयोग करने के लिए) की परिभाषा को विभाजित कर सकते हैं, जो अंततः अलग परियोजनाओं में डीएएल घटक के लिए ज़िम्मेदार है। आप टी 4 टेम्पलेट्स को संपादित कर सकते हैं या ऑनलाइन ढूंढ सकते हैं जो इकाई मॉडल से इकाई और संदर्भ वर्ग परिभाषाओं को रेपोजिटरी और वर्क डिज़ाइन पैटर्न के यूनिट का समर्थन करने के लिए उत्पन्न करेंगे, जहां आप सीधे किसी इकाई संदर्भ का संदर्भ नहीं लेते हैं बल्कि इसके बजाय यह एक आईरिपोजिटरी इंटरफ़ेस को कार्यान्वित करता है , जो आपके कोड को अधिक टेस्टेबल बनाता है। मैंने व्यक्तिगत रूप से एनएचबीर्नेट के साथ व्यक्तिगत रूप से काम नहीं किया है, लेकिन मेरी समझ यह है कि यह वही काम करने में सक्षम है (और तर्कसंगत रूप से बेहतर काम कर सकता है)।

Answer 4

शायद आपके प्रश्न का उत्तर वास्तव में नहीं, लेकिन फिर भी इसके बारे में सोचना कुछ है।

मैं उन बाधाओं में हूं जहां आपने अपने घटक पदानुक्रम में डेटा पहुंच डाली है। मैं इसे दो कार्यात्मक डोमेन परतों के बीच नहीं रखूंगा। एकल डोमेन मॉडल कक्षाओं के ऊपर "ऊपर" भी नहीं। डेटा एक्सेस, या दृढ़ता, किसी भी डोमेन वर्ग के लिए चिंता नहीं है। यह केवल कुछ ऐसा होना चाहिए जो उनके साथ किया जा सके, ऐसा कुछ न करें जो वे करते हैं।

हालांकि मैं TClient.Save और TClient.Load तरह बातें अब मैं निष्कर्ष है कि यह ग्राहक है कि यह बचाया जा करने की जरूरत है निर्णय करता है के लिए आए हैं, लेकिन उपयोगकर्ता इंटरैक्शन को हुक्म जब एक डोमेन उदाहरण के डेटा की जरूरत है और इसलिए है कोडिंग बाहर शुरू कर दिया लोड किया जाना चाहिए, और जब किसी ग्राहक का डेटा जारी रखा जाना चाहिए, तो बिल्कुल भी। इसलिए मैं अब कोडिंग का समर्थक हूं (जीयूआई में, अधिक विशेष रूप से नियंत्रक जीयूआई में) DataStore.Load(ClientInstance) और DataStore.Save(ClientInstance) जैसी चीजें हैं। यह तब करने के लिए डेटा एक्सेस लेयर तक है, यह जानने के लिए। यह सी # में प्रतिबिंब का उपयोग कर सकता है, या डेल्फी में नई आरटीटीआई का उपयोग सभी क्लाइंट के गुणों पर फिर से करने के लिए किया जा सकता है ताकि यह उन्हें डेटाबेस में भेज सके।

जबकि लेयरिंग चिंताओं को अलग करने के लिए एक बहुत अच्छी अवधारणा है और आपको "आप कॉल कर सकते हैं लेकिन ऊपर नहीं जा सकते" का पालन करके पूरी जगह पर सामान डालने से रोकते हैं, यह लॉगिंग जैसी चीजों को संबोधित करते समय उतना ही मदद नहीं करता है, अपवाद हैंडलिंग, अधिसूचनाएं और उन सभी अन्य रोचक क्रॉस काटने से संबंधित है कि हर दूसरे घटक/परत की जरूरत है।

इसके अलावा, सामान्य परत, क्योंकि यह एक उपयोगिता परत है, वास्तव में अन्य सभी परतों के लिए सुलभ होनी चाहिए।

+---+ +-------------+ 
| C |<--| Data Access |<--------------------------+ 
| o | +-------------+       | 
| m |   |         | 
| m |   |         | 
| o |   v         | 
| n | +-------------+ +----------------+ +-----+ 
| |<--| Model  +<--| Cross class |<--| GUI | 
| | +-------------+ | business rules | |  | 
| |      |    | |  | 
| |<--------------------|    | |  | 
| |      +----------------+ |  | 
| |           |  | 
| |<-----------------------------------------|  | 
+---+           +-----+ 

INotify कार्यान्वयन कि कॉल:

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

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

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

 +--------------------------------------------+ 
    +-----| Cross cutting concerns      | 
    |  +--------------------------------------------+ 
    v   v^         ^
+---+ +-------------+        | 
| C |<--| Data Access |<--------------------------+ | 
| o | +-------------+       | | 
| m |   |         | | 
| m |   |         | | 
| o |   v         | v 
| n | +-------------+ +----------------+ +-----+ 
| |<--| Model  +<--| Cross class |<--| GUI | 
| | +-------------+ | business rules | |  | 
| |      |    | |  | 
| |<--------------------|    | |  | 
| |      +----------------+ |  | 
| |           |  | 
| |<-----------------------------------------|  | 
+---+           +-----+ 

Answer 5

यदि आप पीओसीओ हैं तो आप अपने प्रोजेक्ट में अपनी डेटा इकाइयों का उपयोग कर सकते हैं। अन्यथा मैं आपके द्वारा किए गए अलग-अलग मॉडल बनाएगा। लेकिन उन्हें एक अलग असेंबली में रखें (डेटाएप प्रोजेक्ट में नहीं)

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

• कोर
• :

  मैंने सोचा सभी परतों स्क्रैप और इसके बजाय कुछ इस तरह (एक आईओसी कंटेनर की आवश्यकता है) का उपयोग करने के लिए उन्हें बताने के लिए था विशिष्टता

• यूजर इंटरफेस (विभाजित इंटरफ़ेस पैटर्न। सेवा इंटरफेस और मॉडल शामिल है) (हो सकता है एक वेब सेवा, WinForms, webapp)

कि सबसे Appl के लिए काम करता है ication। यदि आपको लगता है कि कोर बढ़ता है और बहुत बड़ा हो जाता है तो आप इसे किसी भी उपयोगकर्ता इंटरफेस को प्रभावित किए बिना इसे विभाजित कर सकते हैं।

आप पहले से ही एक ओआरएम का उपयोग कर रहे हैं और क्या आपने सत्यापन के लिए सत्यापन ब्लॉक (फ़्लुएंट वैलिडेशन या डेटा एन्नोटेशन) का उपयोग करने के बारे में सोचा है? सभी परतों में अपने मॉडल को मान्य करना आसान बनाता है।

Answer 6

कई परतों में उपयोग की जाने वाली कक्षाएं मुझे चिंतित करती हैं।

विशेष रूप से जब वे डेटा-मॉडल/आधार/परत से भी बंधे होते हैं।

जैसे ही इन कक्षाओं में कोई बदलाव आया है, आप सभी परतों में पुनः कोडिंग में भाग सकते हैं। दूसरे शब्दों में आप अमूर्तता के सहायक प्रभाव को याद कर रहे हैं।

यह कहा गया है कि रूपांतरण कोड (परत से परत तक) को बनाए रखना बहुत मजेदार नहीं है बल्कि सामान्य कम काम में है।

समाधान के बीच एक इंटरफेस/भूमिकाओं का उपयोग हो सकता है: प्रत्येक परत के लिए इंटरफ़ेस/भूमिका जिसे किसी वस्तु को खेलना चाहिए और परत को पारित करने के लिए उस इंटरफ़ेस का उपयोग करें। ए (साझा) वर्ग को तब एक भूमिका (या उनमें से कई) लागू करना चाहिए। यह एक अधिक ढीले युग्मित प्रणाली प्रदान करेगा।

मैं हालांकि कोई भी सीधे सवाल मैं पूछ रहा था का जवाब आपके इनपुट के लिए हर किसी को धन्यवाद, वहाँ कई विचारों यहाँ मैं लागू करने की योजना में सुधार के लिए कर रहे हैं this neat lecture about DCI (Data, Collaborations, and Interactions)