बिजनेस लॉजिक लेयर (BLL) का क्या उपयोग है?

Question

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

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

Comments

दक्षता बनाम लचीलापन / कोड पुन: उपयोग दुविधा की तरह लगता है।

— नौकरी

@Job - हाँ, विशेष रूप से, क्योंकि यह कोड के पुन: उपयोग (अभी तक) के कम संभावना के साथ एक छोटा सा ऐप है। लेकिन यह आंशिक रूप से सर्वोत्तम अभ्यास का उपयोग करने की कोशिश कर रहा है।

— एंड्रयू अर्नोल्ड 21

मैंने सभी को उकसाया क्योंकि वे सभी महान जवाब हैं; दुर्भाग्य से मैं केवल एक को स्वीकार कर सकता हूं।

— एंड्रयू अर्नाल्ड

Answer 1

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

क्या मैं एक छोटे प्रोजेक्ट के लिए BLL और DAL के संयोजन पर विचार करूंगा? मैं इस तथ्य को छोड़कर, कि मैं जितनी बार हेयर स्टाइल बदलता हूं, उसके बारे में डीएएल प्रौद्योगिकियों को बदल देता हूं, और मुझे अपने क्लाइंट कोड को उससे अलग करने के लिए कुछ करना पसंद है।

Comments

मैंने 20 वर्षों में अपना हेयर स्टाइल नहीं बदला है। मैं अपनी DAL तकनीक को जितनी बार बदलना चाहूँगा, हेयर स्टाइल बदलूँगा।

— एरिक फनकेनबश

कुछ लोग केवल अपने DAL को हर 20 साल में अपडेट करते हैं!

— मार्की

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

— कार्सन 63000

Answer 2

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

Comments

वास्तव में, यह इस तरह से "स्तरों" या "परतों" को अलग करने की कोशिश के साथ समस्या का हिस्सा है। अक्सर बार, कुछ को परतों को पार करना पड़ता है क्योंकि यह उस अलग परत में बेहतर अनुकूल है। एक बढ़िया उदाहरण है SQL क्वेरीज़, जिसमें व्यावसायिक तर्क निर्मित होते हैं। उदाहरण के लिए, आपकी आयु की गणना पूरी तरह से SQL (या ORM) लेयर में अधिक कुशलता से की जा सकती है।

— एरिक फनकेनबस

@ मिस्टर मैन अधिक कुशलता से व्यक्तिपरक है। उस टिप्पणी का मतलब है कि आप जानते हैं कि सामने के छोर पर क्या हो रहा है। यह प्रकृति में बहुत स्थिर है। सुनिश्चित करने के लिए डेटा को ऑप्टिमाइज़ करने के लिए SQL क्वेरी का उपयोग करें लेकिन जब आप UI को बैक-एंड में बाँधना शुरू करते हैं तो एक अच्छी लाइन होती है।

— एरोन मैकिवर

@ मिस्टर मैन: वास्तव में यह हो सकता है। और यह अक्सर सच होता है कि एक परत से दूसरी परत तक "ब्लीड" होती है। असली कला उन्हें अलग करने और उन्हें अलग रखने में है। मुझे पता है, यह हमेशा आसान नहीं होता है ...

— FrustratedWithFormsDesigner

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

— TMN

Answer 3

एंड्रयू,

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

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

Answer 4

ऐसा कुछ भी नहीं है जो कहता है कि आपके पास निश्चित संख्या में स्तरीय या परतें हैं। यह सब आपके प्रोजेक्ट की जटिलता पर निर्भर करता है। MVC के कई सैंपल ऐप्स पर एक नज़र डालें, जैसे कि nerd डिनर या रिकॉर्ड स्टोर .. वे सभी 2 लेयर्स का उपयोग करते हैं, क्योंकि ऐसे अनुप्रयोगों के लिए जिनके पास बहुत कम प्रोसेसिंग लॉजिक है, इसका कोई मतलब नहीं है।

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

मान लीजिए कि आप अपने ORM को Linq से SQL में Entity Framework (या nhibernate) में बदलने का निर्णय लेते हैं। यह संभवतया आपकी प्रस्तुति परत की तुलना में व्यावसायिक परत में इसे बदलने में आसान होगा, क्योंकि प्रस्तुति युगल को प्रस्तुति मॉडल के लिए कस कर देती है।

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

Answer 5

पूरक उजाड़ ग्रह के जवाब के बारे में डोमेन प्रेरित डिजाइन:

ऑनियन आर्किटेक्चर को भी देखें , जो कि डोमेन ड्रिवेन डिजाइन अवधारणाओं के साथ बहुत गठबंधन है।

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

मेरी राय में: व्यापार तर्क परत वह जगह है जहां "शुद्ध वैचारिक समाधान" रहता है। बाकी सिर्फ इंफ्रास्ट्रक्चर कार्यान्वयन विवरण हैं।

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

Answer 6

इस प्रश्न का उत्तर है (IMHO): "क्या मैं अपने DAL को पूरी तरह से बदल सकता हूं और मेरे किसी भी व्यावसायिक तर्क को फिर से लिखना नहीं है"?

इसे अपनी प्रेजेंटेशन लेयर की तरह समझें - GUI को एक अलग तरीके से बदलने के बारे में सोचने के लिए यह काफी सामान्य है, एक मोटी डेस्कटॉप GUI को वेब क्लाइंट के लिए स्वैप किया जाता है, जो iPhone ऐप के लिए स्वैप हो जाता है। बीएलएल / डीएएल के लिए इस तरह से सोचना इतना सामान्य नहीं है क्योंकि वे वास्तव में कभी नहीं मिलते हैं सिवाय इसके कि शायद बहुत समान के लिए (जैसे एक SQLServer DB एक MySQL एक के साथ बदल दिया गया), लेकिन अगर आप कल्पना करते हैं कि आपको अपने डीबी को एक वितरित भंडारण में बदलना पड़ा। सेवा जो एक एपीआई का उपयोग करके एक्सेस की गई थी, आपको स्पष्ट विचार मिल सकता है कि परतें कहां मिलती हैं।