12

Django में, सुझाए गए सॉफ़्टवेयर आर्किटेक्चर मॉडल में सभी व्यावसायिक तर्क और डेटा पहुंच डालना है।django मॉडल = व्यापार तर्क + डेटा का उपयोग? या डेटा एक्सेस परत django मॉडल से अलग किया जाना चाहिए?

लेकिन, कुछ सहयोगियों ने सुझाव दिया है कि डेटा एक्सेस परत व्यापार तर्क (व्यापार सेवा परत) से अलग होना चाहिए। उनका औचित्य यह है कि यदि डेटा डेटा का उपयोग किया जाता है तो डेटा एक्सेस लेयर परिवर्तन को अलग कर सकता है। वे यह भी कहते हैं कि व्यापार तर्क है जो एक से अधिक मॉडल में हो सकता है।

लेकिन, जब मैं अलग-अलग डेटा एक्सेस और व्यापार तर्क परतों का उपयोग करके कोडिंग शुरू करता हूं, तो डाटा एक्सेस लेयर सरल है (मूल रूप से मॉडल कोड जो डीबी स्कीमा को परिभाषित करता है) और ऐसा लगता है कि यह बहुत अधिक मूल्य नहीं है।

क्या डीजेंगो मॉडल से डेटा एक्सेस को अलग करने में वास्तव में मूल्य है या क्या डीजेंगो पहले से ही अपने ओआरएम के साथ पर्याप्त डेटा एक्सेस लेयर प्रदान करता है?

मैं उन डेवलपर्स की तलाश में हूं जिन्होंने डीजेंगो ऐप्स की उचित संख्या लागू की है और पता है कि उनकी राय क्या है। यह एक छोटे से मध्यम आकार के वेब ऐप के लिए है।

+0

डेटा एक्सेस लेयर ओआरएम है। यह ** मॉडल से अलग ** है। आप ओआरएम को बदलने वाले नहीं हैं। आप ** ** डेटाबेस इंजन बदलने जा रहे हैं; और यह ओआरएम परत से पहले से ही छोटा हो गया है। यह स्पष्ट नहीं है कि आपके सहयोगियों का क्या मतलब है "डेटा एक्सेस लेयर"। क्या आप अधिक जानकारी प्रदान कर सकते हैं? –

+0

संभावित डुप्लिकेट [व्यापार तर्क का पृथक्करण और django में डेटा पहुंच] (http://stackoverflow.com/questions/12578908/separation-of-business-logic-and-data-access-in-django) –

+0

@the_drow: ओटी: क्या आप कृपया रोबो-समीक्षा बंद कर सकते हैं और संपादन पर ध्यान दे सकते हैं? [यह सुझाव दिया गया है] (http://stackoverflow.com/review/suggested-edits/3992632) एक स्पष्ट टिप्पणी थी, एक सुझाए गए संपादन को स्वीकार नहीं किया जाना चाहिए था। –

उत्तर

24

Django विकास के तीन वर्षों के बाद, मैंने निम्नलिखित सीखा है।

ओआरएम एक्सेस लेयर है। और कुछ भी जरूरी नहीं है।

व्यापार तर्क का 50% मॉडल में चला जाता है। इनमें से कुछ फॉर्म में दोहराया या बढ़ाया गया है।

व्यापार तर्क का 20% फॉर्म में जाता है। उदाहरण के लिए, सभी डेटा सत्यापन फॉर्म में है। कुछ मामलों में, फॉर्म एक सामान्य डोमेन (मॉडल में अनुमत) को कुछ सबसेट में संकीर्ण करेंगे जो समस्या, व्यापार या उद्योग के लिए विशिष्ट है।

व्यापार तर्क का 20% आवेदन में अन्य मॉड्यूल में हवाओं को हवाओं में डाल देता है। ये मॉड्यूल मॉडल और रूपों से ऊपर हैं, लेकिन दृश्य कार्यों के नीचे, रीस्टफुल वेब सेवाएं और कमांड लाइन ऐप्स।

प्रबंधन तर्क का 10% प्रबंधन कमांड इंटरफ़ेस का उपयोग कर कमांड लाइन ऐप्स में हवाओं को हवा देता है। यह फ़ाइल लोड, निष्कर्ष, और यादृच्छिक थोक परिवर्तन है।

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

अभी तक आविष्कार करने की कोशिश कर रहा है एक और एक्सेस लेयर शून्य-मूल्य अभ्यास है ।

+2

django के लिए एक और अधिक स्पष्ट आर्किटेक्चर के बारे में कुछ उत्कृष्ट विवरण: http://stackoverflow.com/questions/12578908/separation-of-business-logic-and-data-access-in-django?rq=1 – TaiwanGrapefruitTea

+0

मैं असहमत हूं कि ओआरएम डाटा एक्सेस लेयर है; ओआरएम में डाटा एक्सेस लेयर का * अधिकांश * शामिल है। अपने मॉडलों में सीधे एक ओआरएम का उपयोग करना और मॉडल विशेषताओं के साथ डेटाबेस टेबल को जोड़ना आपके अनुप्रयोग को डेटाबेस से संबंधित और एक विशिष्ट ओआरएम (उदाहरण के लिए Django) जोड़ता है। यह सक्रिय रिकॉर्ड डिज़ाइन पैटर्न से निहित है, जो Django (https://docs.djangoproject.com/en/dev/misc/design-philosophies/) का उपयोग करता है। यदि आप व्यापार तर्क और डेटा पहुंच को बेकार करना चाहते हैं, तो आपको इसके बजाय डेटा मैपर डिज़ाइन पैटर्न का उपयोग करना चाहिए (उदाहरण के लिए SQLAlchemy ORM इसका समर्थन करता है)। हालांकि, कुछ ऐप्स के लिए यह अधिक हो सकता है। –

1

उत्तर आपके आवेदन की आवश्यकताओं पर निर्भर करता है।

उन अनुप्रयोगों के लिए जो हमेशा संबंधपरक डेटाबेस का उपयोग करेंगे और एक विशिष्ट ओआरएम के साथ जोड़ा जा सकता है, आपको डेटा एक्सेस और मॉडल को अलग करने की आवश्यकता नहीं है। Django ORM सक्रिय रिकॉर्ड डिज़ाइन पैटर्न पर आधारित है, जो डेटा एक्सेस और मॉडल का मानना ​​है। प्रो सादगी है, कॉन कम लचीलापन है।

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

मैं अधिक जानकारी के लिए मार्टिन फाउलर द्वारा लिखित "एंटरप्राइज़ एप्लिकेशन आर्किटेक्चर के पैटर्न" पुस्तक की अनुशंसा करता हूं।

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