डेटा परत सर्वोत्तम अभ्यास

मैं एक नए आवेदन में डेटा परत को लागू करने के सर्वोत्तम तरीके के बारे में एक सहयोगी के साथ "चर्चा" के बीच में हूं।

एक दृष्टिकोण यह है कि डेटा परत को व्यावसायिक वस्तुओं (हमारे स्वयं के वर्ग जो एक इकाई का प्रतिनिधित्व करते हैं) से अवगत होना चाहिए, और उस वस्तु के साथ काम करने में सक्षम होना चाहिए।

विरोधी दृष्टिकोण यह है कि डेटा परत ऑब्जेक्ट-अज्ञेयवादी होनी चाहिए, और पूरी तरह से सरल डेटा प्रकारों (स्ट्रिंग्स, बूल, तिथियां इत्यादि) को संभालना चाहिए।

मैं देख सकता हूं कि दोनों दृष्टिकोण मान्य हो सकते हैं, लेकिन मेरा स्वयं का दृष्टिकोण यह है कि मैं पूर्व को पसंद करता हूं। इस तरह, यदि डेटा स्टोरेज माध्यम बदलता है, तो व्यापार परत को (आवश्यक) को नई डेटा परत को समायोजित करने के लिए बदलना नहीं पड़ता है। इसलिए SQL डेटा स्टोर से एक धारावाहिक xml फाइल सिस्टम स्टोर में बदलने के लिए यह एक छोटी सी बात होगी।

मेरे सहयोगी का दृष्टिकोण यह है कि डेटा परत को ऑब्जेक्ट परिभाषाओं के बारे में पता नहीं होना चाहिए, और जब तक डेटा उचित रूप से पारित किया जाता है, वह पर्याप्त है।

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

TIA

0
ro fr bn

8 उत्तर

उन अनुप्रयोगों में जहां हम NHibernate का उपयोग करते हैं, जवाब "बीच में कहीं" बन जाता है, उसमें, जबकि xml मैपिंग परिभाषाएं (वे निर्दिष्ट करती हैं कि कौन सी तालिका किस वस्तु से संबंधित है और कौन से कॉलम संबंधित हैं, आदि) व्यापार ऑब्जेक्ट स्तर में स्पष्ट रूप से हैं ।

वे एक सामान्य डेटा सत्र प्रबंधक को पास कर दिए जाते हैं जो किसी भी व्यावसायिक वस्तुओं से अवगत नहीं है; एकमात्र आवश्यकता यह है कि सीआरयूडी के लिए पास की जाने वाली व्यावसायिक वस्तुओं में मैपिंग फ़ाइल होनी चाहिए।

0
जोड़ा

मेरे पास एक उत्कृष्ट पुस्तक है, जो इस विषय को कवर करती है, क्लिफ्टन द्वारा डेटा एक्सेस पैटर्न है काटने का निशान लगाना। यह दृढ़ता परत से अपनी व्यावसायिक परत को कम करने के तरीके पर कई अच्छी स्पष्टीकरण और अच्छे विचार हैं। आपको वास्तव में इसे आज़माएं। यह मेरी पसंदीदा किताबों में से एक है।

0
जोड़ा

एक चाल जो मैंने पाई है वह है कि मेरी डेटा परत "संग्रह अज्ञेयवादी" हो। यही है, जब भी मैं अपनी डेटा परत से ऑब्जेक्ट्स की एक सूची वापस करना चाहता हूं, तो मुझे कॉलर को सूची में पास करने के लिए मिलता है। तो इसके बजाय:

public IList GetFoosById(int id) { ... }

मैं यह करता हूँ:

public void GetFoosById(IList foos, int id) { ... }

This lets me pass in a plain old List if that's all I need, or a more intelligent implementation of IList (like ObservableCollection) if I plan to bind to it from the UI. This technique also lets me return stuff from the method like a ValidationResult containing an error message if one occurred.

इसका अभी भी मतलब है कि मेरी डेटा परत मेरी ऑब्जेक्ट परिभाषाओं के बारे में जानता है, लेकिन यह मुझे लचीलापन की एक अतिरिक्त डिग्री देता है।

0
जोड़ा

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

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

0
जोड़ा

यह वास्तव में दुनिया के आपके दृष्टिकोण पर निर्भर करता है - मैं अनिश्चित शिविर में होता था। डीएएल केवल कहानी के बीएएल-अंत में डेटा की आपूर्ति करने के लिए था।

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

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

0
जोड़ा
मैं पूरी तरह सहमत हूँ। डेटा एक्सेस लेयर इत्यादि का डिज़ाइन काफी हद तक धुंधला हो रहा है। जबकि मैं हमेशा प्रस्तुति परतों से अपने व्यापार तर्क को अलग करने का विकल्प चुनता हूं। एमवीसी पैटर्न एफटीडब्ल्यू ;-)
जोड़ा लेखक Tobias N. Sasse, स्रोत

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

0
जोड़ा

पुरानी पोस्ट लेकिन इसी तरह की जानकारी खोजने के लिए मैं यह जो इसे अच्छी तरह से समझाता है।

0
जोड़ा

जेफरी पालेर्मो ने इसके बारे में एक अच्छी पोस्ट लिखी। उन्होंने इसे प्याज आर्किटेक्चर कहा।

0
जोड़ा