क्या डेटाबेस में डोमेन मॉडल एक स्थायी समाधान हो सकता है?


13

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

जो मुझे सबसे ज्यादा परेशान कर रहा है वह यह है कि हमारा मुख्य डेटाबेस डेवलपर (इसलिए "जॉन" कहा जाता है) डेटाबेस में मॉडल स्कीमा रखता है! हम इसे 3 "जादू" तालिकाओं के द्वारा करते हैं; एक डेटाबेस-स्कीमा के लिए, एक टेबल के लिए और एक कॉलम के लिए।

" टेबल्स " में एक रिकॉर्ड सम्मिलित करना -समर्थन (डेटाबेस ट्रिगर के माध्यम से), वास्तविक, संगत तालिका। " पंक्तियों " में एक पंक्ति सम्मिलित करना -इस सन्दर्भ के साथ संदर्भित तालिका को अद्यतन करता है। ये सी # मॉडल बनाने के लिए उसके होममेड सी # -प्रोग्राम द्वारा बारी-बारी से पढ़े जाते हैं, जो कि फ्रंट-डेवलपर्स द्वारा कंट्रोलर्स और आउटवर्ड के लिए उपयोग किए जाते हैं।

इसके अलावा, अधिकांश विकास ASP.NET MVC फ्रेमवर्क के अनुसार किया जाता है ।

मैं इस दृष्टिकोण के साथ कुछ खामियों को देखता हूं:

  • हमें उसे ओआरएम बनाए रखने की आवश्यकता है, और उसके पास शायद ही ऐसा करने का समय है (नौकरी की सुरक्षा अच्छी है!)
  • "टेबल्स" और "पंक्तियों" तालिका के लिए ट्रिगर्स त्रुटिपूर्ण हैं। वे टेबल अपडेट का समर्थन नहीं करते हैं, न ही चेक-बाधाओं या अधिक "उन्नत" सुविधाओं का। हालांकि हम निश्चित रूप से उनमें सुधार कर सकते हैं, मुझे अभी तक यकीन नहीं है कि यह रास्ता तय करना है।
  • डेटाबेस में प्रोग्रामेटिक लॉजिक रखना अजीब और प्रतिबंधात्मक लगता है (हालाँकि C # के माध्यम से उसके मॉडल का विस्तार करना संभव है)।
  • उनके C # मॉडल-जनरेटर को 3 लोगों में से एक (जिसमें मैं एक हूं) द्वारा मैन्युअल रूप से चलाया जाना है, और अभी तक एक स्वचालित निर्माण प्रक्रिया में शामिल होने के लिए पर्याप्त परिपक्व नहीं है।

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

यह पोस्ट एक ऐसी चीज़ की ओर अग्रसर है जो एक विचार-विमर्श की तरह लग सकती है, लेकिन यह मेरा उद्देश्य नहीं है। मैं सिर्फ हमारे वास्तुशिल्प दृष्टिकोण के बारे में कुछ स्पष्टीकरण चाहता हूं।

क्या डेटाबेस में डोमेन मॉडल रखना किसी कंपनी के विकास में स्थायी समाधान हो सकता है?


डोमेन मॉडल बहुत ही बारीकी से डोमेन संचालित डिजाइन से जुड़े होते हैं। डोमेन संचालित डिज़ाइन का पूरा बिंदु डेटा संचालित डिज़ाइन से मुक्त होना है, जहाँ डेटा (यानी डेटाबेस) अनुप्रयोग का मूल है। कहा दृष्टिकोण और डोमेन मॉडल वास्तव में एक साथ नहीं चलते हैं। डोमेन संचालित डिज़ाइन प्रथाओं का पालन करते समय, आपको परवाह नहीं है कि डेटा कहाँ से आता है, आप बस इसका उपयोग करते हैं और अपनी व्यावसायिक परत में इस पर तर्क करते हैं।
एंडी

मैं "डेटाबेस में प्रोग्रामेटिक लॉजिक को बनाए रखने" से आपके बारे में थोड़ा स्पष्ट नहीं हूं। क्या आप स्पष्ट कर सकते हैं?
रॉबर्ट हार्वे

कोड में व्यापार तर्क बिल्कुल सही तरीका है। डीबी एक गूंगा डेटास्टोर होना चाहिए, और कुछ नहीं।
एंडी

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

@VladislavRastrusny जो भी कारण है, db में व्यावसायिक तर्क रखना एक अत्यंत खराब डिज़ाइन है।
एंडी

जवाबों:


16

आप एक इनर प्लेटफॉर्म का वर्णन कर रहे हैं

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

जैसा कि कहा गया है, अगर इस प्रक्रिया के अंत उत्पाद है असली टेबल और वास्तविक कक्षाएं मॉडलिंग वास्तविक व्यापार डोमेन वस्तुओं, मैं बहुत ज्यादा नहीं नुकसान इस दृष्टिकोण में अलग उपकरणों की अपरिपक्वता से दिख रहा है,। स्टैक एक्सचेंज वास्तव में अपने स्वयं के, होमग्रॉन ओआरएम का उपयोग करता है, और ऐसा लगता है कि उनके लिए काम किया है। इसलिए मुझे पता है कि इस प्रकार के "कॉटेज" दृष्टिकोण काम कर सकते हैं।

ध्यान दें कि अधिकांश ORM जो "टेबल-प्रथम" दृष्टिकोण लेते हैं, कक्षाओं को बनाने के लिए बस डेटाबेस में टेबल संरचना को देखते हैं। "टेबल" और "पंक्ति" टेबल जो आपके मित्र ने बनाई है, वह केवल मेटाडेटा है जो पहले से ही अधिकांश आधुनिक रिलेशनल डेटाबेस सिस्टम के सिस्टम टेबल में मौजूद है।

आगे पढ़ना
"विज़न" प्रोजेक्ट, आंतरिक प्लेटफ़ॉर्म प्रभाव के बारे में एक सतर्क कहानी
(आप प्रस्तावना को छोड़ सकते हैं और "परिचय विज़न" प्रस्तुत कर रहे हैं)


2
दिलचस्प पढ़ा, मैं निश्चित रूप से धर्मशास्त्र आकर्षित कर सकता हूं। मैं अभी भी नया हूं और अभी के लिए दर्शक बना रहूंगा, लेकिन मैं इसे लेंस के नीचे रखूंगा। एक अच्छी प्रतिक्रिया के लिए धन्यवाद!
क्रिस्टा नोव
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.