बिजनेस लेयर बनाम एसक्यूएल सर्वर

Question

मेरे पास एक ऐसा एप्लिकेशन है जो सदस्यों के लिए जटिल गणना करता है। प्रत्येक सदस्य के पास उनके प्रोफाइल से जुड़े कई अमेरिकी राज्य हो सकते हैं। प्रत्येक राज्य को प्रत्येक पाठ्यक्रम के लिए अलग-अलग गणना मिलती है जो एक सदस्य पूरा करता है।

अभी तक मैं डीबी (एसक्यूएल सर्वर 2008) में गणना कर रहा हूं और फिर डेटा को वापस ऐप लेयर पर भेज रहा हूं जहां वे अपना इतिहास देख सकते हैं और फिर प्रत्येक पाठ्यक्रम के लिए प्रमाणपत्र डाउनलोड कर सकते हैं।

मेरे पास एक व्यवसाय तर्क परत है लेकिन वहां बहुत कुछ नहीं होता है। मुझे पता है कि यह बहुत कुछ पूछा गया है लेकिन आपको लगता है कि मुझे इन गणनाओं को कब करना चाहिए: व्यवसाय परत या डेटाबेस? मैं आगे और आगे जा रहा हूँ !!

Answer 1

मैं मूल रूप से एसक्यूएल सर्वर में कुछ भी होता है कि:

• संक्षेप, गिनती का एक बहुत, डेटा की औसत आदि करता है और केवल एक ही मान देता है। मध्यम स्तर पर डेटा की बड़ी मात्रा को स्थानांतरित करने में वास्तव में कोई बिंदु नहीं है, बस एक कॉलम

• बहुत सारी पंक्ति/सेट-आधारित मैनिपुलेशन करता है; यदि आपको प्रतिलिपि बनाने, सम्मिलित करने, बहुत सारे डेटा अपडेट करने की आवश्यकता है, फिर भी, उस डेटा को मध्य स्तर पर खींचने में वास्तव में कोई बिंदु नहीं है और फिर उसे सर्वर पर वापस भेजना - इसे सीधे चलने से सर्वर पर करें। इसके अलावा: T-SQL काफी तेजी आपके बीच स्तरीय में कुछ भी की तुलना में (लगभग डेटा फेरबदल की तरह) सेट आधारित संचालन से निपटने के लिए है हो सकता है

संक्षेप में: ग्राहक के लिए डेटा की बड़ी मात्रा में भेजने से बचने की कोशिश/मध्यम-स्तरीय/व्यापार परत जब तक कि आपको पूरी तरह से नहीं करना है (उदाहरण के लिए क्योंकि आप किसी डेटाबेस में संग्रहीत फ़ाइल को डाउनलोड करना चाहते हैं, या यदि आप वास्तव में की आवश्यकता है ताकि आपके 200 ऐप में ऑब्जेक्ट्स में भौतिक रूप से प्रदर्शित होने के लिए उन पंक्तियों को कहीं भी प्रदर्शित किया जा सके या संचालित किया जा सके चालू)

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

---

मैं इसे मध्यम स्तरीय/व्यापार तर्क परत

• अगर यह व्यापक तर्क चेकिंग, स्ट्रिंग पार्स, पैटर्न मिलान और इसके आगे के लिए आवश्यक में डाल दिया जाएगा; T-SQL उन चीजों

• अगर यह एक वेब सेवा को फोन कि

• तरह के खिलाफ अपने डेटा, या कुछ मान्य करने के लिए कुछ डेटा प्राप्त करने के लिए अगर यह एक व्यापार तर्क आपरेशन के अधिक आवश्यक जैसी चीजों की आवश्यकता पर बेकार है (बजाय सख्त "परमाणु" डेटाबेस संचालन)

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

Answer 2

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

यदि आपका व्यवसाय तर्क स्तर अधिक नहीं कर रहा है और बस SQL ​​सर्वर से डेटा को कॉलर में पास कर रहा है, तो शायद आपको इसकी आवश्यकता नहीं है।

Answer 3

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

एक बिंदु बनाने के लिए अभियंता चीजों के ऊपर, अंतिम लक्ष्य यह होगा कि उस विषय स्थान में काम कर रहे सभी अनुप्रयोगों के लिए व्यवसाय तर्क परत का उपयोग संगठन में किया जाता है। अर्थात। एक सेवा आदि में लिपटे

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

व्यवसाय तर्क परत को यह कैसे किया जाता है इसे एप्लिकेशन के उन हिस्सों से छुपाया जाना चाहिए।

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