व्यापार तर्क परत

Question

के रूप में संग्रहीत प्रक्रियाओं का उपयोग करना मैं जिस कंपनी के लिए काम कर रहा हूं वह वर्तमान में संग्रहीत प्रक्रियाओं (एमएसएसक्यूएल सर्वर बैकएंड में) का उपयोग अपने व्यवसाय तर्क परत के रूप में कर रहा है। वास्तविक व्यापार तर्क डीएलएल सिर्फ एसप्रॉक्स को कॉल करता है और मूल रूप से यूआई (घटनाओं, डेटा बाध्यकारी, आदि) का प्रबंधन करता है

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

क्या मेरे कार्यस्थल में "सर्वोत्तम व्यवहार" गलत है? या मैं बस इस पर विचार कर रहा हूँ?

Answer 1

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

• तर्क BLL में निहित भंडारण माध्यम और की 'नास्तिक' हो सकता है: हालांकि, पिछले 10 वर्षों में परियोजनाओं की एक श्रृंखला से अधिक मेरे अपने अनुभव से, यहाँ मेरी टिप्पणियों BLL dll दृष्टिकोण का समर्थन कर रहे हैं इसलिए अधिक बदलने के लिए लचीला
• फाइनर अनुप्रयोगों कि डेटासंग्रह पर भरोसा करते हैं की श्रेणी में व्यापार पर नियंत्रण कणों का अनुमतियाँ (यद्यपि यह कैसे अक्सर ऐसा होता है बहस का मुद्दा है)। इसके द्वारा मेरा मतलब है टेबल जिनकी अखंडता के स्तर पर बनाए रखा जाना चाहिए, यह व्यवसाय के भीतर उपयोग में है।
• बीएलएल तर्क को में निहित कक्षाओं में शामिल किया जा सकता है जिसमें व्यापार के अन्य क्षेत्रों में का पुन: उपयोग किया जा सकता है और प्रोजेक्ट। वर्ग भी एक सील बंद वर्ग के रूप में लिखा जा सकता है या एक्स्टेंसिबल अपने लक्ष्य 'दर्शकों'
• इकाई परीक्षण के आधार पर - इस (मेरी अनुभव में) अगर इस्तेमाल किया सपा के अंदर एक काले रंग की कला है। जावा/सी # आदि के तहत, यह एक मानक है और कुछ अब अनिवार्य अभ्यास कहेंगे।
• रखरखाव। एक BLL dll के भीतर अच्छी तरह से संगठित इंटरफेस परिदृश्य रखकर, आप मौजूदा तर्क तोड़ने
• पोर्टेबिलिटी के बिना यह अपने कक्षाओं का विस्तार करने के डेवलपर्स के समर्थन के लिए आसान बनाते हैं।आपका बीएलएल ( भाषा कार्यान्वयन के आधार पर) विभिन्न प्लेटफ़ॉर्म पर होस्ट किया जा सकता है। इसी तरह, डेटासंग्रह की implemetation के इंजेक्शन सचमुच mysql के लिए एक xml फ़ाइल से कुछ भी, mssql postgres आदि, हो सकता है आदि
• मानकीकरण। डेटा आर्किटेक्ट बिल्कुल परिभाषित कर सकता है कि प्रत्येक डेटा तत्व डेटाबेस से लिया जाना चाहिए और कैसे प्रत्येक आइटम सहेजा जाना चाहिए (यह एक डीएएल डीएल में बेहतर होगा)। इस प्रकार, परियोजना पर नए डेवलपर्स के साथ-साथ अनुभवी, प्रविष्टि की लागत कम हो गई है।

सूची जारी है, लेकिन यह बीएलएल दृष्टिकोण को अपनाने के लिए प्रमुख प्रोस के शीर्ष हैं।

पर कई स्पिन करने के लिए FWD देख रहे हैं यह एक :)

जिम

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

Answer 2

हम ऐसा करते हैं।

ऐसा इसलिए है क्योंकि हम ऐसे परिदृश्यों का समर्थन करते हैं जहां उपयोगकर्ता इच्छित सॉफ़्टवेयर (जैसे, SQL प्रबंधन स्टूडियो, ओएसक्ल और एक्सेल) के अलावा प्रोग्राम का उपयोग करके डीबी से कनेक्ट होते हैं।

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

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

Answer 3

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

Answer 4

मैं संग्रहित प्रक्रियाओं, छोटे क्षुधा में सिवाय इसके कि मैं बाहर कोड़ा क्योंकि संग्रहित प्रक्रियाओं के साथ चारों ओर खिलवाड़ थोड़ा अतिरिक्त समय लगता है का उपयोग करना पसंद (मैं "व्यक्तिपरक" टैग जोड़ा)।

Christopherous 5000:

• Business Logic: Database or Application Layer

• Should the data access layer contain business logic?

: आप अभी भी संग्रहित प्रक्रियाओं

मैं इन दो इसी तरह के सवाल के जवाब से सहमत करते हैं साथ इकाई परीक्षण कर सकते हैं

Answer 5

ऐसा लगता है कि आपके बिजनेस लेयर वास्तव में डेटा लेयर है और आपके एप्लिकेशन में बिजनेस लेयर नहीं है, लेकिन मैं digress ...

सर्वोत्तम व्यवहार समय के साथ अतिरंजित और बदल जाते हैं। यदि वे काम कर रहे हैं और वे इसके साथ संतुष्ट हैं, तो ऐसा नहीं किया जा सकता है।

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

आवेदन सर्वोत्तम इरादे से लिखा गया था। मूल डेवलपर समय, अनुभव और प्रौद्योगिकी के साथ बाध्य था।

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

Answer 6

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

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

यदि आपके पास काम मिल गया है, तो बस इसके साथ काम करने के तरीके को समझें।

Answer 7

यह निर्भर करता है।

यह इस बात पर निर्भर करता है कि आप व्यवसाय तर्क कह रहे हैं।

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

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

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

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

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

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

Answer 8

क्या होगा यदि आपका सहकर्मी MySQL के साथ आपकी व्यावसायिक परत का पुन: उपयोग करना चाहे? आप उसे बताएंगे कि यह असंभव है क्योंकि कुछ व्यवसाय परत SQL सर्वर में रहती है ..