लगभग 8 वर्षों के लिए मेरी अधिकांश परियोजनाओं पर हाइबरनेट का उपयोग करने के बाद, मैं एक ऐसी कंपनी पर उतरा हूं जो इसके उपयोग को हतोत्साहित करती है और चाहती है कि आवेदन केवल संग्रहीत प्रक्रियाओं के माध्यम से डीबी के साथ बातचीत करें।
कुछ हफ़्ते के लिए ऐसा करने के बाद, मैं उस एप्लिकेशन का एक समृद्ध डोमेन मॉडल नहीं बना पा रहा हूं जिसे मैं बनाना शुरू कर रहा हूं, और एप्लिकेशन बस एक (भयानक) लेनदेन स्क्रिप्ट की तरह दिखता है।
मैंने पाया कुछ मुद्दों में से हैं:
- संग्रहीत कार्यविधियों के रूप में ऑब्जेक्ट ग्राफ़ को नेविगेट नहीं किया जा सकता है, बस डेटा की न्यूनतम मात्रा को लोड करता है, जिसका अर्थ है कि कभी-कभी हमारे पास विभिन्न क्षेत्रों के साथ समान वस्तुएं हैं। एक उदाहरण है: हमारे पास एक ग्राहक से सभी डेटा प्राप्त करने के लिए एक संग्रहीत प्रक्रिया है, और दूसरा खाता जानकारी और ग्राहक से कुछ क्षेत्रों को पुनर्प्राप्त करने के लिए है।
- हेल्पर वर्गों में बहुत सारे तर्क समाप्त हो जाते हैं, इसलिए कोड अधिक संरचित हो जाता है (पुरानी सी संरचनाओं के रूप में उपयोग की जाने वाली संस्थाओं के साथ)।
- अधिक उबाऊ मचान कोड, क्योंकि कोई रूपरेखा नहीं है जो परिणाम को संग्रहीत प्रक्रिया से सेट करता है और इसे एक इकाई में रखता है।
मेरे प्रश्न हैं:
- क्या कोई भी ऐसी ही स्थिति में है और स्टोर प्रक्रिया के दृष्टिकोण से सहमत नहीं है? तुमने क्या किया?
- क्या संग्रहीत प्रक्रियाओं का उपयोग करने का वास्तविक लाभ है? "कोई भी एक ड्रॉप टेबल जारी नहीं कर सकता" के मूर्खतापूर्ण बिंदु के अलावा।
- क्या संग्रहीत प्रक्रियाओं का उपयोग करके एक समृद्ध डोमेन बनाने का एक तरीका है? मुझे पता है कि ऑब्जेक्ट ग्राफ़ को नेविगेट करने में सक्षम होने के लिए संस्थाओं में डीएओ / रिपोजिटरीज़ को इंजेक्ट करने के लिए एओपी का उपयोग करने की संभावना है। मुझे यह विकल्प पसंद नहीं है क्योंकि यह वूडू के बहुत करीब है।
निष्कर्ष
सबसे पहले, आप सभी को आपके उत्तर के लिए धन्यवाद। मैं जिस निष्कर्ष पर पहुंचा हूं वह यह है कि ORM रिच डोमेन मॉडल (जैसा कि कुछ लोगों ने उल्लेख किया है) के निर्माण को सक्षम नहीं करते हैं, लेकिन यह (अक्सर दोहराव वाले) काम की मात्रा को सरल करता है। निम्नलिखित निष्कर्ष का अधिक विस्तृत विवरण है, लेकिन किसी भी हार्ड डेटा पर आधारित नहीं है।
अधिकांश अनुप्रयोग अनुरोध करते हैं और अन्य प्रणालियों को जानकारी भेजते हैं। ऐसा करने के लिए, हम मॉडल की शर्तों (जैसे एक व्यावसायिक घटना) में एक अमूर्त बनाते हैं और डोमेन मॉडल घटना को भेजता है या प्राप्त करता है। घटना को आमतौर पर मॉडल से जानकारी के एक छोटे सबसेट की जरूरत होती है, लेकिन पूरे मॉडल की नहीं। एक ऑनलाइन दुकान में उदाहरण के लिए, एक भुगतान गेटवे कुछ उपयोगकर्ता जानकारी और उपयोगकर्ता को चार्ज करने के लिए कुल का अनुरोध करता है, लेकिन खरीदारी के इतिहास, उपलब्ध उत्पादों और सभी ग्राहक आधार की आवश्यकता नहीं होती है। इसलिए घटना में डेटा का एक छोटा और विशिष्ट सेट है।
यदि हम किसी एप्लिकेशन के डेटाबेस को एक बाहरी सिस्टम के रूप में लेते हैं, तो हमें एक एब्स्ट्रैक्शन बनाने की आवश्यकता होती है जो हमें डेटाबेस मॉडल संस्थाओं को डेटाबेस में मैप करने की अनुमति देता है ( जैसा कि NimChimpsky ने उल्लेख किया है , डेटा-मैपर का उपयोग करके)। स्पष्ट अंतर यह है कि अब हमें प्रत्येक मॉडल इकाई के लिए डेटाबेस (या तो एक लीगेसी स्कीमा या संग्रहीत कार्यविधियाँ) के लिए मैपिंग की आवश्यकता है, अतिरिक्त दर्द के साथ, क्योंकि दोनों सिंक में नहीं हैं, एक डोमेन इकाई आंशिक रूप से मैप हो सकती है। एक डेटाबेस इकाई के लिए (जैसे एक UserCredentials वर्ग जिसमें केवल उपयोगकर्ता नाम और पासवर्ड होता है, जो एक अन्य तालिका में मौजूद उपयोगकर्ता तालिका में मैप किया जाता है), या एक डोमेन मॉडल इकाई एक से अधिक डेटाबेस इकाई के लिए मैप कर सकती है (उदाहरण के लिए यदि कोई एक है- मेज पर एक मानचित्रण, लेकिन हम सिर्फ एक कक्षा में सभी डेटा चाहते हैं)।
कुछ संस्थाओं के साथ एक आवेदन में, अतिरिक्त काम की मात्रा छोटी हो सकती है यदि संस्थाओं को अनुप्रस्थ करने की कोई आवश्यकता नहीं है, लेकिन यह तब बढ़ जाती है जब संस्थाओं को अनुप्रस्थ करने की एक सशर्त आवश्यकता होती है (और इस प्रकार हम किसी प्रकार के आलसी को लागू करना चाह सकते हैं) लोड हो रहा है')। जैसे-जैसे कोई एप्लिकेशन अधिक इकाइयाँ बढ़ाता है, यह काम बढ़ता जाता है (और मुझे लगता है कि यह गैर-रैखिक रूप से बढ़ता है)। यहाँ मेरी धारणा यह है कि हम एक ORM को पुनः प्राप्त करने का प्रयास नहीं करते हैं।
DB को एक बाहरी प्रणाली के रूप में मानने का एक फायदा यह है कि हम उन स्थितियों के आसपास कोड कर सकते हैं जिनमें हम एक एप्लिकेशन के 2 अलग-अलग संस्करण चाहते हैं, जिसमें प्रत्येक एप्लिकेशन का एक अलग मैपिंग होता है। उत्पादन के लिए निरंतर प्रसव के परिदृश्य में यह और अधिक दिलचस्प हो जाता है ... लेकिन मुझे लगता है कि यह कुछ हद तक ओआरएम के साथ भी संभव है।
मैं सुरक्षा पहलू को खारिज करने जा रहा हूं, इस आधार पर कि एक डेवलपर, भले ही उसके पास डेटाबेस तक पहुंच नहीं है, वह सबसे अधिक प्राप्त कर सकता है यदि सिस्टम में संग्रहीत सभी जानकारी नहीं है, बस दुर्भावनापूर्ण कोड इंजेक्ट करके (जैसे। मुझे विश्वास नहीं हो रहा है कि मैं ग्राहकों की क्रेडिट कार्ड के विवरण को लॉग करने वाली लाइन को हटाना भूल गया था, प्रिय प्रभु! )।
छोटा अद्यतन (6/6/2012)
संग्रहीत प्रक्रियाएं (कम से कम ओरेकल में) शून्य डाउनटाइम के साथ निरंतर वितरण जैसे कुछ भी करने से रोकती हैं, क्योंकि तालिकाओं की संरचना में कोई भी परिवर्तन प्रक्रियाओं और ट्रिगर को अमान्य कर देगा। तो उस समय के दौरान जब डीबी को अपडेट किया जा रहा है, एप्लिकेशन भी नीचे होगा। ओरेकल इस एडिशन-बेस्ड रिडिफाइनमेंट के लिए एक समाधान प्रदान करता है , लेकिन मैंने इस सुविधा के बारे में पूछे गए कुछ डीबीए में उल्लेख किया है कि इसे खराब रूप से प्रत्यारोपित किया गया था और वे इसे एक उत्पादन डीबी में नहीं डालेंगे।