आदर्शवादी के लिए हमारा व्यावसायिक तर्क कहाँ है?

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

डेटाबेस के प्रकाश में ऑब्जेक्ट और प्रक्रियात्मक प्रोग्रामिंग

इस लेख के लेखक लिखते हैं:

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

और परिभाषा के रूप में इसके बारे में लिखते हैं। और वह इसे तभी उचित ठहराता है जब वह क्लाइंट-सर्वर आर्किटेक्चर के बारे में बात करता है:

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

ज्यादातर मामलों में, मध्य लिंक केवल कनेक्शन पूल के प्रबंधन के लिए मौजूद था, लेकिन कुछ मामलों में व्यवसाय तर्क मध्य लिंक पर जाना शुरू हो गया क्योंकि संग्रहीत भाषा प्रक्रियाओं की तुलना में व्यावसायिक तर्क को लागू करने के लिए विकास भाषाएँ (C ++, VB, डेल्फी, जावा) बहुत बेहतर थीं। यह जल्द ही स्पष्ट हो गया कि मध्य तर्क व्यापार तर्क के लिए सबसे अच्छी जगह थी।

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

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

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

रिलेशनल डेटाबेस मॉडल बिजनेस लॉजिक का हिस्सा है।

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

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

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

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

आदर्शवादी की दुनिया को हिला देना

ऊपर किए गए सुधारों के साथ, मैंने रिलेशनल डेटा मॉडल और बिजनेस लॉजिक के बिजनेस मॉडल को अलग करने के साथ बहुत सारे एप्लिकेशन लागू किए। लेकिन मेरी पतला दुनिया एक बार काफी हिल गई।

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

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

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

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

लेकिन आखिरकार, इस तथ्य को कि हम व्यापारिक तर्क को वस्तु पद्धति में अलग करते थे, हमारे लिए बिल्कुल भी उपयोगी नहीं था, क्योंकि हमें सिर्फ एक संग्रहीत प्रक्रिया की आवश्यकता है जो कि केवल कतार से भुगतान का आदेश देगी। हां, इस मामले में, व्यापार तर्क संग्रहीत प्रक्रियाओं में हो जाता है।

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

3-स्तरीय वास्तुकला, मानती है कि व्यापार तर्क सर्वर (मध्य स्तरीय) पर है और इस कार्य के लिए क्लाइंट को बायपास करता है। लेकिन सबसे पहले, हमने अतिरिक्त लिंक पेश किया, और दूसरी बात, यह फिर से इस कार्य में एक क्लाइंट की भूमिका निभाता है - यह डेटाबेस से डेटा पंप करता है, इसे प्रोसेस करता है और इसे वापस लिखता है। और यह सब सिर्फ एक वस्तु भाषा में व्यापार तर्क को संसाधित करने के लिए सुविधाजनक बनाने के लिए है। क्या कीमत महान है?

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

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

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

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

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

देखने का एक और चरम बिंदु

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

किन मामलों में इसे उचित ठहराया जा सकता है?

ऐसा नहीं है, मैंने एक ब्राउज़र गेम बनाने के लिए अपने स्टार्टअप के बारे में लिखा था। और यह वहां है कि इस तरह के दृष्टिकोण का उपयोग वास्तव में किया जाता है - डेटाबेस में सभी व्यापारिक तर्क। इसकी क्या वजह रही?

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

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

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

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

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

डेटाबेस में व्यावसायिक तर्क की उपस्थिति बस कोई अन्य वास्तु दोष नहीं है।