हमें इकाई वस्तुओं की आवश्यकता क्यों है?


138

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

मुझे विश्वास नहीं है कि इकाई वस्तुओं का अस्तित्व होना चाहिए।

    :

    इकाई वस्तुओं से मेरा ठेठ बातें हम हमारे अनुप्रयोगों के लिए निर्माण करने के लिए करते हैं, "व्यक्ति", "खाता", "आदेश", आदि जैसे मतलब

    मेरे वर्तमान डिजाइन दर्शन यह है

  • सभी डेटाबेस एक्सेस संग्रहीत प्रक्रियाओं के माध्यम से पूरा किया जाना चाहिए।
  • जब भी आप डेटा की जरूरत है, एक संग्रहीत प्रक्रिया कॉल और एक DataTable

(नोट में एक SqlDataReader या पंक्तियों पर पुनरावृति: मैं भी जावा ईई के साथ उद्यम अनुप्रयोगों का निर्माण किया है, जावा लोगों के लिए के समान स्थानापन्न कृपया मेरी .NET उदाहरण)

मैं एंटी-ओओ नहीं हूं। मैं विभिन्न उद्देश्यों के लिए बहुत से वर्ग लिखता हूं, सिर्फ संस्थाओं में नहीं। मैं स्वीकार करूंगा कि मेरे द्वारा लिखे गए वर्गों का एक बड़ा हिस्सा स्थैतिक सहायक वर्ग हैं।

मैं खिलौने नहीं बना रहा हूं। मैं कई मशीनों पर तैनात बड़े, उच्च मात्रा वाले लेनदेन अनुप्रयोगों के बारे में बात कर रहा हूं। वेब अनुप्रयोग, विंडोज सेवाएं, वेब सेवाएं, बी 2 बी इंटरैक्शन, आप इसे नाम दें।

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

मैं युद्ध-परीक्षण निष्कर्ष पर आया हूं कि इकाई वस्तुएं हमारे रास्ते में आ रही हैं, और हमारे जीवन होंगे उनके बिना बहुत आसान है।

इस सरल उदाहरण पर विचार करें: आपको अपने आवेदन में एक निश्चित पृष्ठ के बारे में एक समर्थन कॉल मिलता है जो सही तरीके से काम नहीं कर रहा है, शायद फ़ील्ड में से एक ऐसा नहीं होना चाहिए जैसा कि होना चाहिए। मेरे मॉडल के साथ, समस्या को खोजने के लिए आवंटित डेवलपर ठीक 3 फ़ाइलें खुलता है। एक एएसपीएक्स, एक एएसपीएक्स.सीएस और संग्रहीत प्रक्रिया के साथ एक एसक्यूएल फ़ाइल। समस्या, जो संग्रहित प्रक्रिया कॉल में अनुपलब्ध पैरामीटर हो सकती है, हल करने में कुछ मिनट लगते हैं। लेकिन किसी भी इकाई मॉडल के साथ, आप हमेशा डीबगर को फायर कर देंगे, कोड के माध्यम से कदम उठाना शुरू करेंगे, और आप विजुअल स्टूडियो में 15-20 फाइलें खोल सकते हैं। जब तक आप ढेर के नीचे नीचे जाते हैं, तब आप भूल गए कि आपने कहां से शुरू किया था। हम केवल एक ही समय में अपने सिर में इतनी सारी चीजें रख सकते हैं। सॉफ़्टवेयर अविश्वसनीय रूप से जटिल है बिना किसी अनावश्यक परतों को जोड़कर।

विकास जटिलता और समस्या निवारण मेरे पकड़ के सिर्फ एक तरफ हैं।

अब स्केलेबिलिटी के बारे में बात करते हैं।

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

यदि आप लोगों को भौतिक डेटा स्टोर से बहुत दूर जाने देते हैं, तो वे एक ऐसे अनुप्रयोग के साथ विनाश बनाएंगे जिसे स्केल करने की आवश्यकता है।

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

[संपादित करें]

ऐसा लगता है कि इस सवाल का फिर अचानक सक्रिय है, तो अब है कि हम नई टिप्पणी सुविधा मैं सीधे कई जवाब पर टिप्पणी की है की है। उत्तरों के लिए धन्यवाद, मुझे लगता है कि यह एक स्वस्थ चर्चा है।

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

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

किसी ऐसे व्यक्ति से पूछें जो लंबे समय से उद्योग में रहा है और लंबे समय तक रहने वाले अनुप्रयोगों के साथ काम किया है: डेटाबेस पर रहते हुए कितने एप्लिकेशन और यूआई परतें आ गई हैं और चली गई हैं? डेटा प्राप्त करने के लिए एसक्यूएल उत्पन्न करने वाली 4 या 5 अलग-अलग दृढ़ता परतें होने पर डेटाबेस को ट्यून और रीफैक्टर करना कितना मुश्किल है? आप कुछ भी नहीं बदल सकते! ओआरएम या एसक्यूएल उत्पन्न करने वाला कोई भी कोड पत्थर में अपना डेटाबेस लॉक करता है।

  0

अपने प्रश्न पढ़ने से, हम बहुत ज्यादा एक जैसे हैं, और अब मैं (3 पार्टी इकाई चौखटे के बारे में सुनने के बाद से, और अब माइक्रोसॉफ्ट के) साल के लिए सटीक एक ही बात सोचा है 03 mar. 092009-03-03 17:23:51

+1

क्या आप कह रहे हैं कि व्यवसाय तर्क सहायक वस्तुएं हैं, या संग्रहीत प्रोसेस में? मैं पूछ रहा हूं कि बहुत से लोग सोचते हैं कि आप बाद में कह रहे हैं ... लेकिन मुझे लगता है कि आप क्या कह रहे हैं कि आपके पास अभी भी कोड किए गए ऑब्जेक्ट्स में व्यवसाय तर्क है, आप सीधे डेटाबेस से डेटा प्राप्त कर रहे हैं और उस डेटा का उपयोग कर रहे हैं डेटा को पकड़ने के लिए विशेष ऑब्जेक्ट्स के लिए ओआरएम या मैपिंग के बजाए। मुझे वैसे ही महसूस होता है - लेकिन वर्तमान में यह देखने के लिए ईएफ 4 का मूल्यांकन भी कर रहा हूं कि यह इसके लायक हो सकता है या नहीं। 14 jun. 102010-06-14 18:32:10

  0

"नवप्रवर्तनकर्ता उपभोक्ता प्रायः वे लोग होते हैं जो खराब हो जाते हैं।" - 11 sep. 122012-09-11 13:29:28

  0

अनुभव वाले किसी व्यक्ति को मैंने 2500 से अधिक एसपीआरओसी के साथ एक सिस्टम विरासत में मिला है जहां एप्लिकेशन को एसपीआरओसी को सक्रिय करने और उनके आउटपुट को समझने के साधनों के रूप में देखा जाता है। प्रत्येक डेटा को पढ़ने और लिखने के लिए इसका स्वयं का एसपीआरओसी है। नियंत्रण के कोई केंद्रीय बिंदु नहीं हैं। यह ग्रेनाइट के रूप में घृणित और लचीला है। मैं डेटाबेस को अनुकूलित करने पर विचार करता हूं। 2500 एसपीआरसीएस ने मुझे अपने स्थान पर रखा। सुव्यवस्थित डोमेन परत और पुनः उपयोग करने योग्य डीएएल कोड के साथ एक प्रणाली की तुलना में यह बीमार कल्पना की तरह दिखता है और एक समर्थन दुःस्वप्न है। सरल कार्यों में घंटों लगते हैं और आत्मा नष्ट हो जाती है। एसपीआरओसी का इस्तेमाल उच्च लोड या विशेष तरीकों के लिए किया जाना चाहिए आईएमओ 19 may. 142014-05-19 15:29:19

  0

अपने "डिबगिंग" उदाहरण के बारे में: यूनिट परीक्षणों के साथ, आप चीजें गलत होने पर और अधिक तेज़ी से जान लेंगे। 15 dec. 162016-12-15 08:36:13

25

एक कारण - अपने डोमेन मॉडल को अपने डेटाबेस मॉडल से अलग करना।

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

+9

मुझे यह कहना है कि कम से कम एंटरप्राइज़ अनुप्रयोगों के लिए मैं वास्तव में असहमत हूं। डेटा आवेदन है। 12 sep. 082008-09-12 02:54:59

+3

आप एक ही डेटा के दो अलग-अलग मॉडल क्यों चाहते हैं? 07 dec. 082008-12-07 22:45:31

+3

क्योंकि कुछ उद्देश्यों के लिए, मॉडल की एक व्याख्या अधिक उपयुक्त हो सकती है। कुछ तर्क पंक्तियों की तुलना में वस्तुओं पर बहुत बेहतर काम करता है। 23 dec. 082008-12-23 15:01:14

+1

मुझे लगता है कि यह एक अच्छा विचार खराब तरीके से लागू किया गया है। 14 jul. 092009-07-14 16:36:17


4

मुझे आपका प्रश्न वास्तव में दिलचस्प लगता है।
आमतौर पर मुझे एप्लिकेशन के व्यावसायिक तर्क को समाहित करने के लिए संस्थाओं की वस्तुओं की आवश्यकता होती है। डेटा तर्क में इस तर्क को धक्का देने के लिए यह वास्तव में जटिल और अपर्याप्त होगा।
इन संस्थाओं से बचने के लिए आप क्या करेंगे? आपके मन में क्या समाधान है?

  0

यह 09 jul. 102010-07-09 01:49:19


7

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

  0

वाह के रूप में बेहतर होगा, कोई और जो इस पर मेरे जैसा सोचता है ... मेरे ऐप्स लगभग हमेशा डेटा के हेरफेर के बारे में हैं, यही वह वास्तव में करता है। 14 jun. 102010-06-14 18:10:38

  0

यह अब एक टिप्पणी के रूप में बेहतर होगा कि उन सुविधाओं को उपलब्ध हैं 09 jul. 102010-07-09 01:48:39

  0

मुझे पैडेंटिक होने के लिए क्षमा करें, लेकिन चूंकि यह एक लोकप्रिय सवाल है, और आपने जो गलती की है वह एक आम है, मुझे लगा जैसे मुझे इसे इंगित करना चाहिए। "कम समय" सही है, लेकिन "कम लोग" और "कम गलतियों" को "कम लोग" और "कम गलतियों" होना चाहिए। यदि आपके पास कम आटा है, तो आप कम कुकीज़ बना सकते हैं। (इसके अलावा, यदि आप बहुत अधिक आटा का उपयोग करते हैं, तो आप बहुत अधिक कुकीज़ बनायेंगे - कम आम तौर पर भूल गए भेद।) फिर, मेरी माफ़ी; बस मददगार होने की कोशिश कर रहा है। 28 jan. 112011-01-28 18:29:55


3

मैं Dan's answer में भी जोड़ना चाहता हूं जो दोनों मॉडलों को अलग करने से आपके डेटाबेस को विभिन्न डेटाबेस सर्वरों या यहां तक ​​कि डेटाबेस मॉडल पर चलाने में सक्षम हो सकता है।


2

@jdecuyper, एक अधिकतम मैं अपने आप को दोहराना चाहता हूं "यदि आपका व्यवसाय तर्क आपके डेटाबेस में नहीं है, तो यह केवल एक सिफारिश है"। मुझे लगता है कि पॉल नील्सन ने कहा कि उनकी एक किताब में। आवेदन परतें और यूआई आते हैं और जाते हैं, लेकिन डेटा आमतौर पर बहुत लंबे समय तक रहता है।

मैं इकाई वस्तुओं से कैसे बचूं? अधिकतर संग्रहीत प्रक्रियाएं। मैं यह भी स्वीकार करता हूं कि व्यवसाय तर्क किसी भी अनुप्रयोग में सभी परतों तक पहुंचने लगता है चाहे आप इसका इरादा रखते हों या नहीं। युग्मन की एक निश्चित मात्रा अंतर्निहित और अपरिहार्य है।

  0

मैं मानता हूं कि एप्लिकेशन में व्यवसाय तर्क केवल अन्य तरीकों के लिए खाते में प्रवेश करने में विफल रहता है, डेटा हटाया जा सकता है, हटाया जा सकता है या बदला जा सकता है। यह आम तौर पर सड़क अखंडता की समस्याओं का कारण बनता है। 03 dec. 082008-12-03 19:17:28

  0

और ऑब्जेक्ट की दुनिया और रिलेशनल दुनिया के बीच मेल-मिलाप को संभालने के लिए आपको हमेशा सेवा परत का उपयोग क्यों करना चाहिए। प्रत्येक परत के माध्यम से व्यापार तर्क खून बह रहा है सबसे निश्चित रूप से अपरिहार्य नहीं है। 14 may. 132013-05-14 19:58:44


59

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

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

  0

क्रिस्टोफर ऐसा लगता है कि आप इस प्रश्न को किसी अन्य प्रश्न से जोड़कर पुनरुत्थान कर रहे हैं। मैं सोच रहा हूं कि "समृद्ध बातचीत" से आपका क्या मतलब है, और वस्तुओं के बिना उन्हें लागू करने के लिए यह अव्यवहारिक कैसे होगा? 12 sep. 082008-09-12 02:57:30

+4

वस्तुओं के साथ किया जा सकता है जो कुछ भी वस्तुओं के बिना किया जा सकता है। मुझे लगता है कि ओओ डिज़ाइन आम तौर पर "जटिल" करने के लिए गैर-ओओ तरीकों से कहीं अधिक आसान होता है, लेकिन मैं समझता हूं कि यह सभी के लिए काम नहीं करता है। 12 sep. 082008-09-12 10:32:21

  0

मैं सहमत हूं - "ऑब्जेक्ट्स का उपयोग कब करें" का उत्तर इस बात पर निर्भर करता है कि ऑब्जेक्ट्स के गुणों को व्यवसाय तर्क में कार्रवाइयों या परिवर्तन की आवश्यकता हो सकती है या नहीं। उदाहरण के लिए उपयोगकर्ता या व्यक्ति के उदाहरणों में पासवर्ड और लॉगिन नाम हो सकता है -> आपके कोड क्रियाएं उन मानों के अनुसार बदलती हैं जो मूल्य हैं। इसके विपरीत यदि आपके पास कोई उत्पाद होगा, तो आप डीबी से डेटासेट प्राप्त करने और बस जीयूआई बनाने के बजाय प्रदर्शन (कुछ और नहीं, कोई अन्य क्रिया नहीं) करते थे। 18 apr. 092009-04-18 08:20:07

+5

एक संतुलन है। धर्म से बचें और चुनें कि क्या काम करता है। 17 jun. 102010-06-17 13:24:58

  0

@ जेफ डेविस: प्रेरणादायक 16 nov. 102010-11-16 19:26:41


0

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

जो भी आप कर रहे हैं, यह ओओपी नहीं है। यह गलत नहीं है, यह सिर्फ ओओपी नहीं है, और यह आपके समाधान को हर समस्या के लिए लागू करने के लिए समझ में नहीं आता है।

  0

डेटा * हमेशा * पहले आता है। इसका कारण है कि आपके पास कंप्यूटर प्रोग्राम पहले स्थान पर है। तो "डेटाबेस पहले" संभवतः ऐप्स डिज़ाइन करने के लिए एकमात्र वैध दृष्टिकोण है। 15 nov. 082008-11-15 15:54:47


27

सिद्धांत कहता है कि अत्यधिक समेकित, कमजोर युग्मित कार्यान्वयन आगे बढ़ने का तरीका है।

तो मुझे लगता है कि आप उस दृष्टिकोण पर सवाल उठा रहे हैं, अर्थात् चिंताओं को अलग करना।

क्या मेरी aspx.cs फ़ाइल डेटाबेस के साथ बातचीत कर रही है, एक स्पोक को कॉल करना और IDataReader को समझना चाहिए?

एक टीम के माहौल में, विशेष रूप से जहां आपके पास एप्लिकेशन के एएसपीएक्स हिस्से से निपटने वाले कम तकनीकी लोग हैं, मुझे इन लोगों को "स्पर्श" करने में सक्षम होने की आवश्यकता नहीं है।

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

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

इसके अलावा, आपका दृष्टिकोण आपके डेटाबेस में रहने के लिए आपके एप्लिकेशन के व्यावसायिक तर्क की वकालत करता है? यह मेरे लिए गलत लगता है, एसक्यूएल डेटा पूछताछ में वास्तव में अच्छा है, और नहीं, imho, व्यापार तर्क व्यक्त करना।

दिलचस्प विचार हालांकि, हालांकि यह एएसपीएक्स में एसक्यूएल से एक कदम दूर महसूस करता है, जो मेरे बुरे पुराने असंगठित एएसपी दिनों से मुझे डरता है।

  0

मैं मानता हूं कि कोड-बैक के दौरान बहुत सारे गतिशील एसक्यूएल छिड़काव बुरा है। आपको डीबी को स्पष्ट और विशिष्ट कॉल करना होगा। स्थैतिक सहायक विधियों में लपेटने वाले स्पोक कॉल ओआरएम मार्ग से नीचे जाने के बिना अलग-अलग अलगाव प्राप्त करते हैं। 12 sep. 082008-09-12 03:01:19

+1

हालांकि मैंने कभी भी एएसपी पर्यावरण में काम नहीं किया है, मुझे यकीन है कि कुछ कम तकनीकी लोग कुछ क्लाइंट साइड जावास्क्रिप्ट कोड के साथ अपने मोजे उड़ा देंगे, जिसके परिणामस्वरूप तकनीकी के लिए किसी भी क्रैपी इंटरफ़ेस के बावजूद एक सुंदर उपयोगकर्ता अनुभव होता है बैक-एंड। 09 feb. 102010-02-09 09:24:23

  0

मैं यहां आपके साथ सहमत हूं और मुझे कुछ क्लाइंट साइड जावास्क्रिप्ट भी करने के लिए जाना जाता है, जिसके परिणामस्वरूप बहुत ही कमजोर उपयोगकर्ता अनुभव नहीं हुआ, भले ही मैं खुद ऐसा कहूं। मुझे लगता है कि बैक-एंड इंटरफेस द्वारा विचार करना मुश्किल नहीं है और किसी भी क्लाइंट साइड प्रोग्रामर को इसके बारे में चिंता करने की ज़रूरत नहीं है, क्योंकि मैंने अपनी चिंताओं को अलग करने का प्रयास किया है। 09 feb. 102010-02-09 17:12:54

+2

"यह मेरे लिए गलत लगता है, एसक्यूएल डेटा पूछताछ में वास्तव में अच्छा है, और नहीं, imho, व्यापार तर्क व्यक्त करना।" - जब तक आप इसका उपयोग नहीं करते हैं, पीएल/एसक्यूएल, जो एसक्यूएल के साथ (और कसकर एकीकृत) के समृद्ध प्रोग्रामिंग भाषा को जोड़ता है, और आपका कोड डेटाबेस के अंदर संग्रहीत होता है। नेटवर्क राउंडट्रिप्स से बचकर प्रदर्शन को बढ़ावा देता है। और आपके क्लाइंट तर्क को समाहित करता है चाहे वह क्लाइंट डेटाबेस से कनेक्ट हो। 15 dec. 102010-12-15 14:27:11


3

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

लेकिन यदि कोई इकाई वस्तु नहीं है, तो उनके बारे में बात करने के लिए बहुत कुछ नहीं होगा।

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

यह बनाए रखने की बात आने पर समय बचाता है।

प्रस्तुति तर्क और डेटा पहुंच से आवेदन तर्क विभाजित करके, और उनके बीच डीटीओ पास करके, आप उन्हें रद्द कर देते हैं। उन्हें स्वतंत्र रूप से बदलने की अनुमति है।

+3

बहुत से लोग डी-युग्मन ला रहे हैं, और एक परत को दूसरे को प्रभावित किए बिना बदल सकते हैं। संग्रहित प्रक्रियाएं किसी भी ओआरएम से बेहतर होती हैं! मैं मूल रूप से डेटा मॉडल को बदल सकता हूं, और जब तक प्रक्रियाएं एक ही डेटा लौटाती हैं, कुछ भी टूटता नहीं है। 12 sep. 082008-09-12 03:03:24

+2

मेरी राय में संग्रहीत प्रक्रियाओं और एक इकाई मॉडल पारस्परिक रूप से अनन्य नहीं हैं। संग्रहीत प्रक्रियाएं आपके इकाई मॉडल को स्टोर करने के लिए एक तंत्र प्रदान कर सकती हैं। सवाल यह है: क्या आपका व्यवसाय तर्क संस्थाओं के साथ काम करता है या सीधे संग्रहित प्रक्रियाओं तक पहुंचता है? 05 nov. 082008-11-05 09:46:39


22

मेरे लिए यह उबलता है कि मैं नहीं चाहता कि मेरा एप्लिकेशन इस बात से चिंतित हो कि डेटा कैसे संग्रहीत किया जाता है। मैं शायद यह कहने के लिए थप्पड़ मारूंगा ... लेकिन आपका आवेदन आपका डेटा नहीं है, डेटा एप्लिकेशन का आर्टिफैक्ट है। मैं चाहता हूं कि मेरा आवेदन ग्राहकों, आदेशों और वस्तुओं के संदर्भ में सोच रहा हो, न कि डेटासेट्स, डेटाटेबल्स और डेटारो जैसी तकनीक ... cuz कौन जानता है कि वे कितने समय तक होंगे।

मैं मानता हूं कि हमेशा एक निश्चित मात्रा में युग्मन होता है, लेकिन मैं उस युग्मन को नीचे की ओर ऊपर तक पहुंचने के लिए पसंद करता हूं। मैं अपने पेड़ को बदलने से आसान पेड़ के अंगों और पत्तियों को ट्विक कर सकता हूं।

मैं रिपोर्टिंग के लिए स्प्रेक्स आरक्षित करता हूं क्योंकि प्रश्न सामान्य डेटा एक्सेस के मुकाबले थोड़ा नास्टियर प्राप्त करते हैं।

मैं उस परिदृश्य के ठीक पहले उचित इकाई परीक्षण के साथ सोचने की सोचता हूं जैसे कि एक कॉलम जारी नहीं रहना संभवतः एक समस्या नहीं है।

+3

"आपका आवेदन आपका डेटा नहीं है, डेटा एप्लिकेशन का आर्टिफैक्ट है।" - डेटा डेटा के बिना बेकार है। आवेदन के बिना डेटा का मूल्य बहुत अच्छा है। आवेदन आते हैं और जाते हैं (फिर से लिखे जाते हैं), किसी भी गैर-तुच्छ आवेदन में डेटा हमेशा रखा जाता है। और समय के साथ डेटा मॉडल आश्चर्यजनक रूप से स्थिर रहता है। 15 dec. 102010-12-15 14:32:51


2

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

मैंने देखा है कि व्यवसाय इकाई मॉडल उन मामलों में बहुत अधिक मूल्य प्रदान करता है जहां डेटाबेस के डिज़ाइन डेटा के साथ काम करने के तरीके से अलग है, जो कि बहुत से व्यवसाय सॉफ़्टवेयर में है।

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

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

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


11

मैं आपके द्वारा प्रस्तावित एक उदाहरण के साथ एक उदाहरण के साथ जवाब देना चाहता हूं।

मेरी कंपनी पर मुझे उत्पादों के लिए एक सरल सीआरयूडी अनुभाग बनाना पड़ा, मैं अपनी सभी संस्थाओं और एक अलग डीएएल का निर्माण करता था। बाद में एक और डेवलपर को एक संबंधित तालिका बदलनी पड़ी और उसने कई क्षेत्रों का नाम बदल दिया। मेरे फॉर्म को अपडेट करने के लिए मुझे बदलने वाली एकमात्र फ़ाइल उस तालिका के लिए डीएएल थी।

क्या संस्थाओं (मेरी राय में) एक परियोजना के लिए लाता है:

Ortogonality: एक परत में परिवर्तन अन्य परतों को प्रभावित नहीं कर सकते हैं (बेशक अगर आप इसे माध्यम से तरंग हैं डेटाबेस पर एक बहुत बड़ा परिवर्तन करने के सभी परतें लेकिन सबसे छोटे बदलाव नहीं होंगे)।

टेस्टेबिलिटी: आप अपने डेटाबेस को छूने के साथ अपने तर्क का परीक्षण कर सकते हैं। यह आपके परीक्षणों पर प्रदर्शन बढ़ाता है (आपको उन्हें अधिक बार चलाने की इजाजत देता है)।

चिंताओं का पृथक्करण: एक बड़े उत्पाद में आप डेटाबेस को डीबीए को असाइन कर सकते हैं और वह इसे नरक को अनुकूलित कर सकता है। मॉडल को एक व्यापार विशेषज्ञ को सौंपें जिसमें इसे डिजाइन करने के लिए आवश्यक ज्ञान हो। डेवलपर्स अधिक webforms आदि पर अनुभव करने के लिए अलग-अलग रूपों निरुपित ..

अंत में मुझे लगता है कि सबसे ORM mappers संग्रहित प्रक्रियाओं का समर्थन के बाद से है कि तुम क्या प्रयोग कर रहे हैं है जोड़ना चाहते हैं।

चीयर्स।

+2

संग्रहीत प्रक्रियाएं शायद ऑर्थोगोनैलिटी और चिंताओं को अलग करने का सबसे अच्छा उदाहरण हैं। यदि सही तरीके से उपयोग किया जाता है, तो वे पूरी तरह से डेटाबेस को समाहित करते हैं। 12 sep. 082008-09-12 03:04:34

+1

@ एरिक जेड दाढ़ी: हाँ, लेकिन संग्रहीत प्रक्रियाओं के भीतर केवल तर्क को अलग करते समय आप संग्रहित प्रक्रियाओं के आसपास यूनिट परीक्षण कैसे लिख सकते हैं? संग्रहीत प्रक्रियाओं को कसकर डेटाबेस के साथ जोड़ा जाता है, और हम में से अधिकांश ओआरएम प्रकार पसंद नहीं करते हैं। संग्रहीत प्रक्रिया के लिए यूनिट परीक्षण लिखने के लिए आपको डेटाबेस में होने के लिए कुछ डेटा पर भरोसा करना होगा। और आप उस डेटा निर्भरता के बिना बार-बार इस परीक्षण को फिर से चला नहीं सकते हैं। वह परीक्षण जो आप लिखेंगे, अब यूनिट टेस्ट नहीं होगा बल्कि इसके बजाय यह एक इंटीग्रेशन टेस्ट होगा। 30 oct. 092009-10-30 17:40:01


0

दिलचस्प सवाल। कुछ विचार:

  1. यदि आपके सभी व्यावसायिक तर्क आपके डेटाबेस में थे तो आप यूनिट परीक्षण कैसे करेंगे?
  2. आपकी डेटाबेस संरचना में बदलाव नहीं करेगा, विशेष रूप से जो आपके ऐप में कई पृष्ठों को प्रभावित करते हैं, पूरे ऐप में बदलने के लिए एक बड़ी परेशानी हो?

16

एरिक, आप मर चुके हैं। किसी भी वास्तव में स्केलेबल/आसानी से बनाए रखा/मजबूत अनुप्रयोग के लिए केवल वास्तविक जवाब सभी कचरे के साथ बांटना और मूल बातें तक चिपकना है।

मैंने अपने करियर के साथ एक समान प्रक्षेपवक्र का पालन किया है और उसी निष्कर्ष पर आ गया है। बेशक, हम विधर्मी मानते हैं और मजाकिया लगते हैं। लेकिन मेरी चीजें काम करती हैं और अच्छी तरह से काम करती हैं।

कोड की प्रत्येक पंक्ति को संदेह के साथ देखा जाना चाहिए।

+2

निश्चित रूप से, यह निश्चित रूप से अच्छी तरह से काम करता है जब आपको बहुत से कर्मियों के एजेडी संसाधन मिलते हैं लेकिन मुझे लगता है कि यदि आप एक आदमी टीम हैं तो सोचें कि "नई" तकनीकें बहुत मदद कर सकती हैं .. 04 aug. 092009-08-04 15:03:57


4

इकाई वस्तुओं अनुप्रयोग परत पर cacheing सुविधा कर सकते हैं। एक भाग्यशाली कैशिंग कैचिंग शुभकामनाएँ।


0

अच्छा प्रश्न!

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

उदाहरण के लिए,

एक AnswerIterator वस्तु AnswerIterator.Answer वस्तुओं उत्पन्न करता है।हुड के तहत यह सभी संबंधित टिप्पणियों को लाने के लिए सभी उत्तरों को लाने के लिए एक SQL कथन पर पुनरावृत्ति कर रहा है, और एक अन्य SQL कथन। लेकिन इटरेटर का उपयोग करते समय मैं केवल उस उत्तर ऑब्जेक्ट का उपयोग करता हूं जिसमें इस संदर्भ के लिए न्यूनतम गुण हैं। कंकाल कोड के थोड़े से यह करने के लिए लगभग तुच्छ हो जाता है।

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

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


2

एरिक,

कोई भी ढांचा/दृष्टिकोण है कि आप चाहते हैं जाएगा चुनने से आप रोक रहा है। यदि आप "डेटा संचालित/संग्रहीत प्रक्रिया-संचालित" पथ पर जा रहे हैं, तो हर तरह से, इसके लिए जाएं! विशेष रूप से यदि यह वास्तव में, वास्तव में आपको अपने अनुप्रयोगों को ऑन-स्पेक और समय-समय पर वितरित करने में सहायता करता है।

चेतावनी (आपके प्रश्न के लिए एक फ्लिपसाइड) है, आपके सभी व्यवसाय नियम संग्रहीत प्रक्रियाओं पर होना चाहिए, और आपका आवेदन पतली ग्राहक से अधिक कुछ नहीं है।

कहा जा रहा है, यदि आप ओओपी में अपना आवेदन करते हैं तो समान नियम लागू होते हैं: सुसंगत रहें। ओओपी के सिद्धांतों का पालन करें, और कि में आपके डोमेन मॉडल का प्रतिनिधित्व करने के लिए इकाई ऑब्जेक्ट्स बनाना शामिल है।

यहां एकमात्र वास्तविक नियम स्थिरता शब्द है। डीबी-केंद्रित जाने से कोई भी आपको रोक नहीं रहा है। कोई भी आपको पुराने स्कूल संरचित (उर्फ, कार्यात्मक/प्रक्रियात्मक) कार्यक्रम करने से रोक रहा है। नरक, कोई भी कोबोल-स्टाइल कोड करने से रोक नहीं रहा है। लेकिन यदि कोई सफलता प्राप्त करने की इच्छा है, तो इस मार्ग को नीचे जाने के बाद एक आवेदन बहुत ही संगत होना चाहिए।

  0

मैं पूरे ऐप में स्थिरता से सहमत हूं। ईमानदार होने के लिए, मैंने थोड़ी देर पहले अपने वर्तमान प्रोजेक्ट पर दिशानिर्देश बदल दिए और मूल मॉडल का 100% तय करने के लिए कभी भी नहीं मिला, जिससे चीजों को भ्रमित कर दिया जाता है। अच्छे निर्णय सबसे अच्छे तरीके से किए जाते हैं। 12 sep. 082008-09-12 03:26:40

  0

एरिक, वास्तव में सच है। मैं एक बार ओओपी उत्साह था (जिस तरह से इस धागे में अन्य लोग प्रतीत होते हैं) लेकिन मैं ऐसे व्यक्ति से मिला जो एक ऐसी कंपनी का मालिक है जो डीबी संचालित चालकों को अत्यधिक सफल बेच रही है। उसने मेरी दुनिया को हिलाकर रख दिया। मैं अभी भी एक ओओपी/टीडीडी बफ हूं लेकिन मैं अब डीबी-केंद्रित पर फहरा नहीं हूं। 12 sep. 082008-09-12 03:36:15

  0

समस्या यह है कि कभी-कभी लोग अपनी विचारधारा बेचते हैं, तो आप संभावित रूप से एक जीवित बिक्री एचटीएमएल और जावास्क्रिप्ट केवल साइटें बना सकते हैं, यदि आपके पास उन्हें क्रैंक करने के लिए एक अच्छी पद्धति थी। 06 mar. 092009-03-06 16:02:23


0

मेरे ऐप्स में ऑब्जेक्ट्स डेटाबेस से एक-दूसरे से संबंधित होते हैं, लेकिन मुझे स्पॉक्स के बजाय लिंक टू एसक्यूएल का उपयोग करना मुश्किल लगता है, जटिल प्रश्नों को लिखना बहुत आसान बनाता है, विशेष रूप से उन्हें उपयोग करने में सक्षम होना स्थगित निष्पादन। जैसे Image.User.Ratings कहां से। यह मुझे एसक्यूएल में कई शामिल बयानों को काम करने की कोशिश करता है, और & छोड़कर पेजिंग के लिए ले जाएं पंक्ति_नंबर & 'ओवर' कोड को एम्बेड करने के बजाय कोड को सरल बनाता है।

  0

इस तरह से काम करने में एक बड़ा खतरा है। सबसे जटिल प्रश्नों को समाप्त करने के लिए पूरी तरह से एक डीबीए द्वारा पुनः लिखे जाने की आवश्यकता होती है। इंडेक्स ट्यूनिंग की कोई मात्रा नहीं कर सकती है जो कभी-कभी क्वेरी बदलती है। इस प्रकार का लिंक 2 एसक्यूएल बेहद तंग युग्मन है। 12 sep. 082008-09-12 03:22:54


4

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

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

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

एडीओ.NET इकाई ढांचे में अतिरिक्त लाभ है कि आपकी डेटाबेस टेबल को एक दूसरे से विरासत इकाई वर्ग के रूप में देखा जा सकता है, या एक इकाई में समेकित एकाधिक तालिकाओं के कॉलम के रूप में देखा जा सकता है। यदि आपको स्कीमा को बदलने की आवश्यकता है, तो आप वास्तविक एप्लिकेशन कोड को बदले बिना वैचारिक मॉडल से मैपिंग को स्टोरेज स्कीमा में बदल सकते हैं। और फिर, संग्रहित प्रक्रियाओं का उपयोग यहां किया जा सकता है।

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

  0

मुझे लगता है कि एक अच्छा समझौता संग्रहित प्रक्रियाओं के लिए एक ओआरएम मैपिंग करेगा, सिवाय इसके कि इसे आसानी से खराब किया जा सकता है: यदि आप प्रत्येक तालिका के लिए केवल 4 सीआरयूडी प्रोसेस बनाते हैं, तो आपने कुछ भी नहीं किया है। क्या आप बड़ी, मोटे अनाज वाली इकाइयों को मैचों में मैप कर सकते हैं, या क्या आपको वास्तव में कहीं भी नहीं मिल रहा है? 12 sep. 082008-09-12 03:49:08

  0

सीआरयूडी परिचालनों के अतिरिक्त, माइक्रोसॉफ्ट ओआरएम आपको इकाई वर्गों पर विधियों को जोड़ने देता है जो सीधे उस किसी भी संग्रहित प्रो पर मैप करते हैं जिसे आप फेंकना चाहते हैं (बशर्ते कि सभी इनपुट/आउटपुट प्रकार मैपबल हों)। 12 sep. 082008-09-12 04:05:47


8

मुझे लगता है कि आप इस विषय पर "चबाने से ज्यादा काट सकते हैं" हो सकता है। टेड नेवार्ड फिसल नहीं रहा था जब उसने इसे "Vietnam of Computer Science" कहा था।

एक बात मैं पूरी तरह से आप गारंटी ले सकते हैं कि यह इस मामले पर देखने का कोई भी नहीं के दृष्टिकोण बदल जाएगा, के रूप में असंख्य अन्य ब्लॉगों, मंचों, पॉडकास्ट आदि पर इतनी बार साबित हुई है

यह खोलना होगा निश्चित रूप से ठीक है एक विवादास्पद विषय के बारे में विवाद और बहस, यह सिर्फ इतना ही किया गया है कि दोनों "पक्ष" असहमत होने के लिए सहमत हुए हैं और बस लेखन सॉफ्टवेयर के साथ मिल गए हैं।

आप आगे दोनों पक्षों पर पढ़ने कुछ करना चाहते हैं, टेड के ब्लॉग, Ayende Rahein, जिमी निल्सन, स्कॉट Bellware, Alt.Net, स्टीफन फोर्ट, एरिक इवांस आदि पर आलेख देखें

+1

आप सही हैं, ज्यादातर लोग अपनी राय नहीं बदलेंगे। मुझे एहसास है कि स्टैक ओवरफ्लो का ध्यान उद्देश्यपूर्ण प्रश्न माना जाता है, लेकिन व्यक्तिपरक लोग बहुत अधिक मजेदार हैं! निजी तौर पर, मैंने इस चर्चा से बहुत कुछ सीखा है। 12 sep. 082008-09-12 11:18:09

  0

मुझे लगता है कि विभिन्न दृष्टिकोण संदर्भ विशिष्ट हैं और यह चर्चा अलग-अलग दृढ़ता मॉडल से लाभान्वित या अलग-अलग परिदृश्यों को अलग करने के लिए काम कर सकती है। विषय पर विशेषज्ञ अपनी राय जल्दी से नहीं बदलेंगे, लेकिन यह एक प्रश्न साइट है जहां लोग दूसरों के अनुभव की तलाश करते हैं। 17 sep. 082008-09-17 20:50:24

  0

लिंक पर बढ़िया लेख। धन्यवाद। 03 dec. 082008-12-03 07:42:55

  0

वाह। "कंप्यूटर विज्ञान के वियतनाम" लेख के लिंक के लिए +1 जो ओआरएम बनाम गैर ओआरएम के विषय के लिए एक उत्कृष्ट परिचय है। 22 aug. 102010-08-22 20:28:16


3

आप this मिल सकती है comp.object दिलचस्प पर पोस्ट करें।

मैं सहमत या असहमत होने का दावा नहीं कर रहा हूं लेकिन यह दिलचस्प है और (मुझे लगता है) इस विषय से प्रासंगिक है।

  0

यह एक महान पोस्ट है। ओआरएम पर लगभग पूरी तरह से मेरे विचारों को बताता है। 20 sep. 082008-09-20 01:22:53


1

पल में समय की नहीं एक बहुत, लेकिन सिर्फ मेरे सिर के ऊपर से ...

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

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

यहाँ कुछ चीजें है कि आप मन (IMO) में रखना चाहिए, हालांकि इस प्रकार हैं:

  1. जनरेट किया गया SQL कोड बुरा (अपवाद पालन करने के लिए) है। क्षमा करें, मैं जानता हूँ कि बहुत से लोगों को लगता है कि कि यह एक बड़ी समय की बचत होती है, लेकिन मैं कभी नहीं एक प्रणाली है कि तुलना में अधिक कुशल कोड मैं क्या लिख ​​सकता है उत्पन्न कर सकता है और अक्सर कोड सिर्फ सादा भयानक है मिल गया है । आप अक्सर एसक्यूएल कोड के टन उत्पन्न करते हैं जो कभी भी उपयोग नहीं किया जाता है। यहां अपवाद बहुत सरल पैटर्न है, जैसे लुकअप टेबल। हालांकि बहुत से लोग पर ले जाते हैं।
  2. संस्थाएं <> सारणी (या यहां तक ​​कि तार्किक डेटा मॉडल इकाइयां भी आवश्यक हैं)। एक डेटा मॉडल में अक्सर डेटा नियम होते हैं जिन्हें डेटाबेस के जितना संभव हो सके उतना ही लागू किया जाना चाहिए जिसमें नियम पंक्तियां एक दूसरे से संबंधित हो सकती हैं या अन्य समान नियम जो घोषणात्मक आरआई के लिए बहुत जटिल हैं। इन्हें संग्रहित प्रक्रियाओं में संभाला जाना चाहिए। यदि आपकी सभी संग्रहीत प्रक्रियाएं सरल सीआरयूडी प्रोसेस हैं, तो आप ऐसा नहीं कर सकते हैं। इसके शीर्ष पर, सीआरयूडी मॉडल आम तौर पर प्रदर्शन मुद्दों को बनाता है क्योंकि यह नेटवर्क पर नेटवर्क पर राउंड ट्रिप को कम नहीं करता है। यह अक्सर एंटरप्राइज़ एप्लिकेशन में सबसे बड़ी बाधा है।
  0

जेनरेट एसक्यूएल पर सहमति हुई। यह हमेशा हल होने की तुलना में अधिक समस्याओं का कारण बनता है। और मैं बस संग्रहित procs के साथ एक सीआरयूडी परत बनाने के खिलाफ बहुत अधिक हूँ। Procs संभव के रूप में मोटे अनाज के रूप में होना चाहिए। सुनिश्चित नहीं है कि आप "एक एप्लिकेशन" को कैसे परिभाषित करते हैं। 21 oct. 082008-10-21 16:52:40

  0

एक आवेदन से, मेरा मतलब है संगठन में एक समूह द्वारा लिखित एक ही आवेदन। जहां मैं अभी परामर्श कर रहा हूं उनके पास एक कॉर्पोरेट डेटाबेस है जिसे कम से कम तीन अलग-अलग समूहों द्वारा उपयोग किया जाता है, जिसमें उनके बीच सीमित संचार के साथ तीन अलग-अलग अनुप्रयोगों पर काम किया जाता है। 23 oct. 082008-10-23 15:48:47


0

इकाई वस्तुओं पर क्यों रोकें? यदि आपको एंटरप्राइज़ लेवल ऐप में इकाई ऑब्जेक्ट्स के साथ मान नहीं दिखाई देता है, तो बस अपनी डेटा एक्सेस को पूरी तरह कार्यात्मक/प्रक्रियात्मक भाषा में करें और इसे यूआई तक वायर करें। क्यों न सिर्फ सभी ओओ "fluff" काट?

  0

मुझे ओओ को "फ्लफ" के रूप में नहीं दिख रहा है। यह सिर्फ पिछले दशक में, एमएसएफटी, सन, आदि ने 99% वस्तुओं को लिखा है जिनकी हमें कभी आवश्यकता होगी। सिर्फ इसलिए कि मैं ढांचे के शीर्ष पर बहुत से स्थिर वर्ग लिखता हूं, इसका मतलब यह नहीं है कि मैं ओओ का उपयोग नहीं कर रहा हूं। 21 oct. 082008-10-21 16:55:27


4

हमें इस बात के बारे में भी बात करनी चाहिए कि वास्तव में कौन सी संस्थाएं हैं। जब मैं इस चर्चा के माध्यम से पढ़ता हूं, तो मुझे लगता है कि यहां अधिकांश लोग Anemic Domain Model के अर्थ में इकाइयों को देख रहे हैं। बहुत से लोग एनीमिक डोमेन मॉडल को एंटीपेटर्न के रूप में देख रहे हैं!

समृद्ध डोमेन मॉडल में मूल्य है। यही है Domain Driven Design सब कुछ है। मैं व्यक्तिगत रूप से मानता हूं कि ओओ जटिलता को जीतने का एक तरीका है। इसका मतलब न केवल तकनीकी जटिलता (जैसे डाटा-एक्सेस, यूई-बाध्यकारी, सुरक्षा ...) लेकिन व्यापार डोमेन में जटिलता भी है!

यदि हम विश्लेषण, मॉडल, डिजाइन करने के लिए ओओ तकनीकों को लागू कर सकते हैं और हमारी व्यावसायिक समस्याओं को लागू कर सकते हैं, तो यह गैर-तुच्छ अनुप्रयोगों की रखरखाव और विस्तारशीलता के लिए एक जबरदस्त लाभ है!

आपकी संस्थाओं और आपकी तालिकाओं के बीच अंतर हैं। संस्थाओं को आपके मॉडल का प्रतिनिधित्व करना चाहिए, टेबल सिर्फ आपके मॉडल के डेटा-पहलू का प्रतिनिधित्व करते हैं!

यह सच है कि डेटा ऐप्स से अधिक समय तक रहता है, लेकिन this quoteDavid Laribee से मानें: मॉडल हमेशा के लिए हैं ... डेटा एक सुखद दुष्प्रभाव है।

इस विषय पर कुछ और अधिक लिंक:

+1

सचमुच, मुझे विश्वास है कि डेटा इसके आसपास के सॉफ़्टवेयर से अधिक समय तक रहता है, क्योंकि व्यवसाय की वास्तविक समझ के साथ सॉफ़्टवेयर को डिजाइन करने के लिए अक्सर बहुत कम ध्यान दिया जा रहा है। 04 mar. 092009-03-04 18:19:52


0

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

मुझे आश्चर्य है कि डेटाबेस के लिए एक isam persistence मॉडल का उपयोग करना बेहतर विचार नहीं होगा; ओओ के लिए एक बेहतर प्रतिबाधा मैच; तालिकाओं के रूप में डेटा के मूल विचार पर अधिक समझौता; ओओ दृढ़ता के पारंपरिक कलाकृतियों के साथ अधिक संगत। एक अच्छा उदाहरण यह है कि एफके और उनके संगठन अधिक स्पष्ट हो सकते हैं।

RoR डेटाबेस डेटाबेस स्लग होने के लिए एक प्रतिनिधि है, और मुझे संदेह है कि यह समस्या कारण का एक बड़ा हिस्सा है।

क्या किसी ने ActiveRecord कार्यान्वयन के लिए isam डेटाबेस का उपयोग करने का प्रयास किया है?


2

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

लेकिन यदि आपके पास 100 टेबल वाली डेटाबेस है जो प्रत्येक तालिका के लिए केवल 4 सीआरडी प्रक्रियाओं के बराबर होती है जो केवल मूल सीआरयूडी ऑपरेशंस के लिए होती है जो 400 संग्रहीत प्रक्रियाओं को बनाए रखने की आवश्यकता होती है और दृढ़ता से टाइप नहीं की जाती हैं, इसलिए टाइपों के लिए अतिसंवेदनशील होते हैं और न ही यूनिट परीक्षण किया जा सकता है। क्या होता है जब आप एक नया सीटीओ प्राप्त करते हैं जो ओपन सोर्स इवांजेलिस्ट है और आरडीबीएमएस को SQL सर्वर से MySQL में बदलना चाहता है?

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

सॉफ़्टवेयर डिज़ाइन के साथ कोई चांदी की बुलेट नहीं है और यह वास्तव में इस बात पर निर्भर करता है कि प्राथमिकताएं कहां हैं, मेरे लिए यह यूनिट टेस्टेबल कोड और कमजोर युग्मित घटकों में है जिसे आसानी से उपभोग किया जा सकता है।

बस मेरे 2 सेंट

  0

नहीं, एंटरप्राइज़ एप्लिकेशन की मेरी परिभाषा विपरीत है। स्कीमा अक्सर बदलता है, और डीबी का उपयोग करने वाले कई अनुप्रयोग हैं, और यह कई बाहरी भागीदारों के साथ इंटरऑपरेट करता है। एक * असली * एंटरप्राइज़ ऐप में, आप कभी भी कभी नहीं, कभी भी * एक अलग आरडीबीएमएस में बदल जाएंगे। यह बस नहीं होता है। 11 nov. 082008-11-11 18:57:23

  0

और प्रत्येक तालिका के लिए 4 प्रोसेस बनाना एक बुरा अभ्यास है। यह आपको ओआरएम से जेनरेट किए गए एसक्यूएल की तरह डेटा मॉडल से कसकर जोड़ता है ताकि यह आपको कुछ भी खरीद न सके। प्रत्येक तालिका पर केवल सीआरयूडी नहीं, प्रोसेस को मोटे अनाज वाले व्यवसायिक संचालन की आवश्यकता होती है। 11 nov. 082008-11-11 19:04:16

  0

लेकिन क्या यह उत्तर नहीं है ?: आपको जितना अधिक कोड लिखना होगा, उतना ही आपको बड़े पैमाने पर प्रोग्रामिंग समर्थन के लिए विशेषताओं की आवश्यकता होगी: encapsulation, स्ट्रिंग टाइपिंग, रीफैक्टरिंग, परिष्कृत शैली और त्रुटि जांच आदि; जावा और .NET के पास इस क्षेत्र में समर्थन का भरपूर धन है, संग्रहीत प्रक्रिया भाषाएं नहीं हैं। 01 apr. 092009-04-01 16:09:16


4

वास्तव में दिलचस्प सवाल है। ईमानदारी से मैं साबित नहीं कर सकता कि संस्थाएं क्यों अच्छी हैं। लेकिन मैं अपनी राय साझा कर सकता हूं कि मुझे उन्हें क्यों पसंद है। जहां आदेश से आया

void exportOrder(Order order, String fileName){...}; 

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

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

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

अनुमापकता यहां दिलचस्प बात है - वेबसाइट जो भारी scalability की आवश्यकता होती है (फेसबुक की तरह, LiveJournal, Flickr) डीबी तपस्वी दृष्टिकोण का उपयोग करते हैं के अधिकांश, जब डीबी संभव और scalability मुद्दों के रूप में दुर्लभ के रूप में प्रयोग किया जाता है कैशिंग द्वारा हल कर रहे हैं, विशेष रूप से राम उपयोग द्वारा। http://highscalability.com/ पर कुछ दिलचस्प लेख हैं।

+2

एंटरप्राइज़ अनुप्रयोगों में स्केलेबिलिटी अक्सर कैशिंग द्वारा हल करने योग्य नहीं होती है, क्योंकि इसमें से अधिकतर लाखों पंक्तियों के साथ तालिकाओं पर अक्सर लेनदेन संबंधी डेटा बदल रहा है। मैं फेसबुक एट देखता हूं। अल। उच्च मात्रा वाली वेब साइट्स के रूप में, जहां हार्ड हिस्सा इतने सारे वेब अनुरोधों की सेवा कर रहा है। 11 nov. 082008-11-11 19:01:03


0

मैं संग्रहित procs के के पक्ष में "पत्थर में अपना डेटाबेस लॉक करें" तर्क के बारे में परेशान हूं। मैं अपना ActiveRecord मॉडल ले सकता हूं और इसे MySQL से Postgres से SQLite तक ले जा सकता हूं, बहुत बहुत धन्यवाद। जब तक मैं उन सभी को फिर से लिखना नहीं चाहता था तब तक मैं कुछ भी संग्रहित प्रो-आधारित के साथ ऐसा नहीं कर सका।

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

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

  0

हां, आप एसक्यूएल में कई पुनरावृत्ति के साथ खत्म हो जाते हैं। आप आम तौर पर प्रदर्शन के लिए डीआरवाई का त्याग करते हैं। Procs बहुत मोटे अनाज हैं: वे विशिष्ट उद्देश्यों के लिए मौजूद हैं और भारी पुन: उपयोग नहीं किया जाता है। आप सही हैं, पत्थर में 'स्कीमा' को लॉक करना अधिक उपयुक्त है। 03 dec. 082008-12-03 20:39:25

+1

rdbms विक्रेताओं को बदलने के बारे में तर्क एंटरप्राइज़ एप्लिकेशन पर लागू नहीं है। यदि आपको इस संभावना का सामना करना पड़ता है, तो आप एंटरप्राइज़ ऐप, आईएमओ पर काम नहीं कर रहे हैं। 03 dec. 082008-12-03 20:40:14


2

मैं ओओ और आरडीबी के बीच दूरी की समस्या के लिए एक और कोण प्रदान करना चाहता हूं: इतिहास।

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

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

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

मुझे लगता है कि ओओ के साथ आना चाहिए जब लोगों को लगता है कि वास्तविकता के अन्य पहलू लेखांकन (जो पहले से ही एक मॉडल है) से मॉडल के लिए कठिन हैं। ओओ एक बहुत ही सफल विचार बन गया है, लेकिन ओओ डेटा की दृढ़ता अपेक्षाकृत अविकसित है।आरडीबी/एकाउंटिंग में आसान जीत मिली है, लेकिन ओओ एक बड़ा क्षेत्र है (मूल रूप से सबकुछ जो लेखांकन नहीं कर रहा है)।

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

प्रीवायरर और डीबी 4o कुछ सुझाव हैं, मुझे यकीन है कि ऐसे कुछ भी हैं जिनके बारे में मैंने नहीं सुना है, लेकिन किसी को भी आधा प्रेस नहीं लगता है, हाइबरनेशन।

अच्छी पुरानी फाइलों में अपनी ऑब्जेक्ट्स को संग्रहीत करना बहुउद्देशीय अनुप्रयोगों और विशेष रूप से वेब अनुप्रयोगों के लिए गंभीरता से नहीं लिया जाता है।

ओओ और आरडीबी के बीच चक्कर को बंद करने के लिए मेरे दैनिक संघर्ष में मैं जितना संभव हो ओओ का उपयोग करता हूं लेकिन विरासत को न्यूनतम रखने की कोशिश करता हूं। मैं अक्सर एसपी का उपयोग नहीं करता हूं। मैं केवल उन्नत प्रश्नों का उपयोग उन पहलुओं में करूंगा जो लेखांकन की तरह दिखते हैं।

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

  0

मुझे नहीं लगता कि आपको ओओ के लिए ओआरएम की आवश्यकता है जिसे उपयोगी माना जा सकता है। मैं संग्रहीत प्रोसेस का उपयोग करता हूं और अपने कोड में बहुत से स्थिर सहायक कक्षाएं लिखता हूं, लेकिन उन वर्गों को विशाल .NET ढांचे पर बनाया गया है, जो वस्तुओं का एक शानदार संग्रह है। 03 dec. 082008-12-03 20:46:18

  0

आपका तर्क समझ में आता है, लेकिन मुझे नहीं लगता कि आधार ध्वनि है। मैंने कभी भी ऐसा कुछ नहीं सुना है जिसे आरडीबी के साथ मैप नहीं किया जा सकता है। 14 jul. 092009-07-14 16:40:59


0

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


3

एक प्रश्न: यदि आपके सभी व्यावसायिक तर्क डेटाबेस में फंस गए हैं तो आप डिस्कनेक्ट किए गए एप्लिकेशन कैसे प्रबंधित करते हैं?

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

डेटाबेस पर संग्रहीत प्रक्रियाओं में डोमेन परत को रखने में आपको एक ही प्रकार के एप्लिकेशन के साथ रहना होगा जिसके लिए डेटाबेस में स्थायी रेखा-दृष्टि की आवश्यकता होती है।

यह वातावरण की एक निश्चित कक्षा के लिए ठीक है, लेकिन यह निश्चित रूप से एंटरप्राइज़ अनुप्रयोगों के पूरे स्पेक्ट्रम को कवर नहीं करता है।


1

कभी-कभी, आपका एप्लिकेशन और डेटा परत कसकर युग्मित नहीं होती है। उदाहरण के लिए, आपके पास एक टेलीफोन बिलिंग एप्लिकेशन हो सकता है। बाद में आप एक अलग एप्लिकेशन बनाते हैं जो फोन के उपयोग पर नज़र रखता है) बेहतर विज्ञापन आपको बी) अपने फोन प्लान को अनुकूलित करें।

इन अनुप्रयोगों में अलग-अलग चिंताओं और डेटा आवश्यकताएं हैं (यहां तक ​​कि डेटा एक ही डेटाबेस से बाहर आ रहा है), वे अलग-अलग डिज़ाइन चलाएंगे। यदि आप डेटाबेस को कोड ड्राइव करते हैं तो आपका कोड बेस एक पूर्ण गड़बड़ (या तो एप्लिकेशन में) और एक दुःस्वप्न को बनाए रखने के लिए समाप्त कर सकता है।


1

डेटा स्टोरेज तर्क से अलग डोमेन तर्क वाले अनुप्रयोग किसी भी प्रकार के डेटा स्रोत (डेटाबेस या अन्यथा) या यूआई (वेब ​​या विंडोज़ (या लिनक्स इत्यादि) एप्लिकेशन के अनुकूल हैं।

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

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

इसके अलावा, जबकि मैं सहमत हूं कि संग्रहीत प्रक्रियाओं के बनाम डोमेन तर्क के प्रश्न का कोई निश्चित उत्तर नहीं है। मैं डोमेन तर्क शिविर में हूं (और मुझे लगता है कि वे समय के साथ जीत रहे हैं), क्योंकि मेरा मानना ​​है कि विस्तारित डोमेन तर्क विस्तृत डोमेन तर्क से बनाए रखना कठिन है। लेकिन यह एक पूरी बहस है


0

मुझे नहीं लगता कि इकाई वस्तुओं को स्केलेबिलिटी के साथ क्या करना है, आप शायद ओआरएम टूल्स का उपयोग करने के बारे में बात कर रहे हैं, इस मामले में मैं आपसे सहमत हूं।

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

मैं आपसे सहमत नहीं हूं कि इकाई वस्तुएं कोड को बनाए रखने के लिए कठिन बनाती हैं, वास्तव में इस वास्तुकला का पूरा उद्देश्य अपने कोड को बनाए रखने और संशोधित करना आसान बनाता है और मैं अभ्यास में यह देखता हूं, मैं लंबे समय तक स्पेगेटी कोड लिखा (3-स्तरीय या एन-स्तरीय आर्किटेक्चर का उपयोग नहीं किया) इसलिए मुझे पता है कि मैं किस बारे में बात कर रहा हूं।

कैशिंग के लिए इकाई वस्तुओं की भी आवश्यकता है, मुझे आश्चर्य है कि यदि आप एंटीटी ऑब्जेक्ट्स का उपयोग नहीं करते हैं तो आप अपने अनुप्रयोगों में डेटा कैश करते हैं, क्या आप डेटासेट या डेटाटेबल्स का उपयोग करते हैं?


0

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

मैं चिपचिपा मिल thigns सभी उत्तर लेकिन आम अंक नहीं पढ़ा है:

  • कोड छोटी गाड़ी, अस्थिर कोड दोहराया है
  • विशाल कक्षाएं हर जगह स्थिर
    कक्षाओं के साथ भरी हुई
  • तर्क जाता है और
    कहीं भी (एएसपीएक्स, स्थिर विधियों, एसक्यूएल, ट्रिगर)
  • एकाधिक
    के साथ इंटरैक्टिंगऑब्जेक्ट्स, सामान्य सुविधाओं को साझा करना प्रोव हार्ड

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

डीबगर, जटिल डोमेन पर भी एक त्वरित शब्द। मुझे लगता है कि बहुत से लोग डरते हैं क्योंकि वे इंटरफेस हिट करते हैं, सभी एक्रोबेटिक्स को समझते हैं जो बहुत उन्नत ओओपी/पॉलिमॉर्फिक कोड में संभव हैं। मैं पूरी तरह से समझता हूं, कभी-कभी आप खो सकते हैं और बिगड़ सकते हैं। यही कारण है कि वे उपकरण बनाते हैं .. मैं 1000 लाइनों के साथ एक humongous विधि की तुलना में 1000 फाइलों के साथ एक समाधान से डर रहा हूँ। और मैंने देखा है कि दोनों इसे मानते हैं या नहीं।

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


0

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

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

दूसरा उद्धृत लाभ यह है कि आप अपना आवेदन ले सकते हैं और इसे एक अलग डेटाबेस पर चला सकते हैं। हाँ, ठीक है, शायद अगर आप पुनर्विक्रय या कुछ के लिए SalesForce की तरह कुछ लिख रहे हैं, तो यह एक लक्ष्य हो सकता है, लेकिन 9 0% या उससे अधिक अनुप्रयोगों के लिए, तो क्या? मुझे "इट्स अ वंडरफुल लाइफ" में पड़ोसी की याद आ रही है, जिसने जॉर्ज को पैसे का जार दिया और कहा: "अगर मैं कभी पति प्राप्त करता हूं तो मैं तलाक के लिए इसे बचा रहा था।" इसे तब तक मत लिखो जब तक आपको इसकी आवश्यकता न हो।

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


0

एक प्रश्न: क्या होगा यदि आपका डेटा स्रोत वेब सेवा थी? मैं वेब सेवाओं के माध्यम से केवल वितरित डेटा का उपयोग कर आवेदन लिखता हूं। क्या मुझे यह लिखने की उम्मीद है कि मेरे डेटा स्रोत आरडीबीएमएस के मुकाबले एक अलग प्रतिमान का उपयोग कर रहे हैं?

मैं नहीं पूछ रहा हूं कि आप आरडीबीएमएस से वेब सेवाओं में स्विच करते हैं (क्योंकि, एक आंतरिक दुकान में, यह असंभव है), मैं पूछ रहा हूं कि जब डेटा वेब सेवाओं से आता है तो आप क्या करते हैं प्रारंभ?

क्या आपका प्रोग्रामिंग मॉडल आरडीबीएमएस होने की तुलना में काफी भिन्न है? यदि ऐसा है, तो आपको रखरखाव पर विचार करने की आवश्यकता है। मेरे डेवलपर्स के पास एक भयानक समय होगा, यदि वे प्रत्येक ऐप में कूदते हैं तो विभिन्न प्रतिमानों का उपयोग करके प्रोग्राम किया जाता है।


0

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

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

जो कुछ भी कहा गया है, मैं आपके साथ हूं कि आपके द्वारा बैठे कारणों के लिए कई बार एक ओआरएम मिल सकता है। अंत में, यह तकनीक पर शासन करने के लिए उबलता है।


0

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

मैं इस प्रश्न को तीन पहलुओं में देखता हूं। लेकिन इससे पहले, मुझे यह कहना होगा: 10 में से 8, अनिवार्य/ओओ-डिजाइन दुनिया (सी/सी ++, जावा, सी #, आदि) से आने वाले प्रोग्रामर को अनुकूलित, कुशल एसक्यूएल कोड लिखना नहीं है । मेरे अनुभव से, ऐसा कोई दुर्लभ है जो आवेदन विकास और SQL विकास दोनों पर अच्छा प्रदर्शन कर सके।

इसके साथ, मैं इस प्रश्न को देखने के लिए तीन पहलुओं को देना चाहता हूं।

पहला: चिंता का विषय कार्यक्रम के अनुसार नहीं, लेकिन संगठनात्मक पदानुक्रम

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

किसी भी डेटाबेस अनुरोध (डेटा या कार्यक्षमता) को किसी अन्य भूमिका में प्रस्तुत किया जाना चाहिए: डेटा आर्किटेक्ट। एस/वह डेटाबेस के विकास, और संभवतः रखरखाव से निपटने वाला होगा। (हालांकि, रखरखाव हिस्सा डीबी व्यवस्थापक का काम होना चाहिए।) ऐसे माहौल में, संग्रहीत प्रक्रिया केवल उपभोग योग्य है; प्रोड पर्यावरण में संग्रहीत प्रक्रिया का स्रोत भी एन्क्रिप्ट किया जाएगा, और प्रोग्रामर को एसपी के स्रोत को देखने की अनुमति नहीं है।

हालांकि, कुछ अन्य संगठनों में, प्रोग्रामर इंटरफेस, मिडलवेयर और डेटा स्टोरेज समेत सभी पहलुओं के विकास की उम्मीद कर रहे हैं। यह बहुमत का मामला है।

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

दूसरा: डेटाबेस की भूमिका: विभिन्न व्याख्याओं के लिए शुद्ध डेटा संग्रहण, या जानकारी की पूर्वनिर्धारित योजनाओं के प्रदाता?

परिभाषा: "डेटा" कच्चे है, जबकि "सूचना" का अर्थ है।

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

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

इसलिए समस्या: संगठन में प्रत्येक शाखा, अपने स्वयं के विशिष्ट प्रोग्रामिंग विभाग (और प्रत्येक शाखा के बीच थोड़ा अंतर-संगठनात्मक व्यवसाय) के साथ, वित्तीय डेटा के एक ही सेट का उपयोग करती है, लेकिन विभिन्न सूत्रों और संचालन के साथ।

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

इस मामले में, संगठन को एक गहन सवाल का सामना करना पड़ता है: क्या डेटाबेस व्याख्या की गई जानकारी प्रदान करता है, या क्या इसे बिना किसी अर्थ के डेटा को सेवा देना चाहिए?

यह तीसरा पहलू में कूदने का एक अच्छा तरीका है।

तीसरा: वैचारिक युद्ध: बनाम बहुउद्देश्यीय एकल, और अखंड बनाम मॉड्यूलर?

उपरोक्त उदाहरण बहुउद्देशीय फैशन में उपयोग किए जाने वाले डेटा का एक स्पष्ट प्रदर्शन है। प्रत्येक शाखा के लिए शेष रहते हुए डेटा अलग-अलग परिदृश्यों में अलग-अलग व्याख्या और उपयोग करता था। और यहाँ मेरा लेना है।

क्या आपका डेटाबेस स्टोर और सेवा करता है, प्रकृति में, बहुउद्देशीय है, और प्रदर्शन एक बड़ी चिंता नहीं है?

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

यदि प्रश्न का कोई भी हिस्सा ऋणात्मक है (यानी यह एकमात्र उद्देश्य है, या प्रदर्शन एक बड़ी बड़ी चिंता है), और यह मानते हुए कि कोई कार्यालय राजनीति रास्ते में नहीं है, तो मैं कहूंगा, बहुमत डालने का एकान्त दृष्टिकोण डेटाबेस में सामान ठीक है। पसंदीदा या नहीं, यह एक वैचारिक पसंद बन जाता है।

मुझे यह धारणा है कि लेखक, प्रश्न लिखने और संपादित करने पर, एकात्मक दृष्टिकोण की राय का समर्थन करता है।मैं इस मामले-दर-मामले पर विचार करते हैं, लेकिन आम तौर पर, मैं इस तरह के दृष्टिकोण में हूँ:

  • सरल CRUD और कुछ नहीं: आंकड़ों के आधार पर ORM
  • सूत्र और कार्यप्रवाह: (CSLA की तरह) मिडलवेयर, में नहीं डेटाबेस
  • रिपोर्टिंग (जब तक प्रदर्शन चिंता का विषय है): निश्चित रूप से डेटाबेस में (प्रदर्शन कारण के लिए)

ऊपर मेरी 2 सेंट है।


0

सॉफ़्टवेयर जो बहुत ही वास्तविक परिस्थितियों पर लागू होने वाली एक बहुत ही सामान्य तरीके से बड़ी समस्या हल करता है, वह आवश्यक रूप से प्रदर्शन लागत के साथ आता है। यह सभी जेनेरिकिटी को संभालने के लिए कोड लेता है और कोड चलाने में समय लगता है।

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

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

मैं वर्तमान में इन मुद्दों के कारण प्रदर्शन समस्याओं की समस्याओं से जूझ रहे अपने कामकाजी दिन बिताता हूं और वे लड़ने के लिए भयानक राक्षस हैं।


0

प्रत्येक दृष्टिकोण में ताकत है। किसी विशेष समस्या के लिए उनकी उपयुक्तता केस-दर-मामले आधार पर तय की जानी चाहिए।

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


मैं एक लिनक्स उपयोगकर्ता हूं। यूनिक्स दर्शन में एक बिंदु यह है कि डेवलपर्स को "टेक्स्ट स्ट्रीम को संभालने के लिए प्रोग्राम लिखना चाहिए, क्योंकि यह एक सार्वभौमिक इंटरफ़ेस है"। यह लिनक्स के बारे में सच है, क्योंकि यह बहुत टेक्स्ट केंद्रित है। grep ^col /var/log/bim-sync | sed 's/.*alt:\([0-9]\{1,\}\).*/\1/g | xargs -I replstr bim-transcoder replstr जैसे कुछ नया हासिल करने के लिए आप असंबद्ध प्रक्रियाओं को एक साथ जोड़ सकते हैं। ये कार्यक्रम एक-दूसरे से पूरी तरह से अनजान हैं, और फिर भी एक नया उद्देश्य प्राप्त करने के लिए आसानी से एक साथ शामिल हो सकते हैं। कारण यह संभव है क्योंकि आप ("गोंद" के लेखक) प्रत्येक प्रक्रिया के इनपुट और आउटपुट स्वरूपों को जानते हैं।

अब, मुझे विश्वास नहीं है कि टेक्स्ट स्ट्रीम हर जगह उचित हैं। पाठ धाराएं आम हैं, लेकिन सार्वभौमिक नहीं हैं। मेरा विकास दर्शन "अच्छी तरह से परिभाषित इनपुट और आउटपुट के साथ प्रोग्राम लिखना" है। इनपुट/आउटपुट जो मैं यहां बात कर रहा हूं वह आवश्यक रूप से मानक इनपुट/आउटपुट नहीं है और जरूरी नहीं है - यह एक कमांड लाइन प्रोग्राम के लिए तर्क हो सकता है, नेटवर्क सॉकेट पर भेजे गए कच्चे बाइट्स, परतों के बीच पारित स्मृति डेटा संरचना में कोड, आदि, आदि। पुराने Input-Process-Output "ब्लैक बॉक्स" के संदर्भ में सॉफ़्टवेयर के बारे में सोचने से आप यूनिक्स में कमांड लाइन उपयोगिता जैसे अपने एप्लिकेशन को लिख सकते हैं - स्वतंत्र रूप से गोंद की एक पतली परत के साथ जो उन्हें एक साथ जोड़ता है।

उदाहरण के तौर पर, आप ऑस्ट्रेलियाई न्यू साउथ वेले के Births, Deaths and Marriages के लिए सॉफ़्टवेयर लिख रहे हैं। जब किसी बच्चे के जन्म का पंजीकरण आता है, तो ऑपरेटर विवरण में प्रवेश करता है, हस्ताक्षरित रूपों को स्कैन करता है और बटन सबमिट करता है। बटन सबमिट करना RegisterBirth कमांड जारी करता है। सॉफ्टवेयर कमांड (जन्मतिथि, अस्पताल, आदि) के विवरण को मान्य करता है, और BirthRegistered ईवेंट उत्सर्जित करता है। इस कार्यक्रम में जन्म के बारे में कई विवरण शामिल हैं, जैसे कि डिलीवरी करने वाले डॉक्टर, चाहे वह प्राकृतिक जन्म हो या सी-सेक्शन द्वारा, यदि यह सी-सेक्शन था, चाहे वह आपातकाल हो, जैविक माता-पिता आदि, आदि। बहुत सारे कोड इस घटना को "प्लग" कर सकते हैं। उदाहरण के लिए, कोड का एक टुकड़ा एक साधारण insert into person... एसक्यूएल कथन जारी कर सकता है, जबकि कोड का एक और टुकड़ा नवजात शिशु को स्टोर करने और अपने जैविक माता-पिता से संबंध रखने के लिए श्रृंखला Neo4j cypher आदेश जारी कर सकता है। कोड का यह दूसरा टुकड़ा पदानुक्रमित "पारिवारिक पेड़" डेटा की बेहद तेज़ क्वेरी की अनुमति देगा। एसक्यूएल डेटाबेस में ऐसे प्रश्न धीमे (और अधिक जटिल) होंगे, भले ही आप adjacency lists or nested sets का उपयोग करें। अभी भी कोड का एक और टुकड़ा उस महीने आपातकालीन सी-सेक्शन की संख्या पर आंकड़े अपडेट कर सकता है, जो ऐतिहासिक कारणों से किसी XML फ़ाइल में संग्रहीत है।

मॉड्यूलरिटी दृढ़ता तंत्र को सारणित करने से नहीं रोकती है। उदाहरण के लिए, आप अपने आवेदन को वेब-सक्षम करने के लिए FastCGI "गोंद परत" लिख सकते हैं: आपके "वेब" द्वारा "इनपुट" HTTP अनुरोध स्वीकार किया जाता है, जो आपके "गोंद परत" के लिए "आउटपुट" फास्टसीजीआई अनुरोध को उत्सर्जित करता है। आपकी फास्टसीजीआई "गोंद परत" इसे इनपुट के रूप में स्वीकार करती है और इसे आपके आवेदन के लिए उपयुक्त आउटपुट फॉर्म में बदल देती है। आपका एप्लिकेशन इनपुट कमांड स्वीकार करता है और ईवेंट या त्रुटियों को उत्सर्जित करता है, जिसे अन्य "गोंद परतों" (जैसे ऊपर दिए गए एसक्यूएल और नियो 4 जे उदाहरण) द्वारा उठाया जा सकता है।

मॉड्यूलरिटी लगभग किसी भी दिशा में जारी रख सकती है। आपके पास कमांड लाइन इंटरफेस, या एक जीयूआई इंटरफ़ेस हो सकता है। आप एक व्यापक, स्वचालित परीक्षण सूट बना सकते हैं। आप तीसरे पक्ष द्वारा लिखित होने के लिए अपना आवेदन खोल सकते हैं। यहां कई अवधारणाएं Domain Driven Design, Command Query Responsibility Segregation और Event Sourcing से संबंधित हैं, तीन अंतर-संबंधित पैटर्न जिन्हें मैंने अविश्वसनीय शक्तिशाली पाया है।

एक इकाई-आधारित दृष्टिकोण का उपयोग करते समय, कई वास्तुशिल्प से संबंधित हैं। उदाहरण के लिए, जेफ़री पालेर्मो द्वारा Onion Architecture और एलिस्टेयर कॉकबर्न द्वारा Ports and Adapters (या हेक्सागोनल आर्किटेक्ट) है। इन सभी आर्किटेक्चरों में सामान्य रूप से परिभाषित इनपुट और आउटपुट के माध्यम से मॉड्यूलरिटी और अबास्ट्रक्शन है, भले ही वे इनपुट/आउटपुट सीमाएं एक ही प्रोग्राम में हों या फिर चाहे वे कई प्रक्रियाएं और नेटवर्क भी फैले हों।

एक इकाई-आधारित दृष्टिकोण मॉड्यूलरिटी और लचीलापन प्रदान करता है। हालांकि, इस दृष्टिकोण के लिए डाउनसाइड्स हैं, जिनमें से तीन महत्वपूर्ण हैं:

  1. सबसे पहले, प्रारंभिक निवेश उच्च है। इसका मतलब है कि ऐसा दृष्टिकोण उन परियोजनाओं के लिए समझ में नहीं आता है जो दायरे में छोटे हैं।

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

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


संदर्भ: