2009-12-11 12 views
6

मान लीजिए कि किसी एप्लिकेशन में मॉडल/प्रेजेंटेशन परत में सभी आवश्यक व्यावसायिक नियम हैं और वे ठीक काम करते हैं। मेरा सवाल यह है कि अनावश्यक व्यवसाय नियमों में से एक है या नहीं (यानी दो तिथियों की अवधि किसी भी अन्य मौजूदा स्पैन को ओवरलैप नहीं कर सकती है) SQL सर्वर जैसे रिपॉजिटरी में उपयोग किया जाना चाहिए।भंडार में व्यापार नियम?

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

यह प्रश्न कई अलग-अलग तकनीकों को फैलाता है इसलिए मैंने जानबूझकर टैग जेनेरिक रखा।

उत्तर

6

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

+0

क्या आप कह रहे हैं कि डेटा से संबंधित नियम * केवल * डेटाबेस में हैं, या वे दोनों व्यवसाय और डेटा परतों में होना चाहिए? यदि बाद में, आप बड़ी परियोजनाओं पर उन्हें सिंक में रखने के लिए किस दृष्टिकोण का उपयोग करते हैं? –

+0

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

+0

बिल्कुल प्रतिक्रिया का प्रकार जिसे मैं ढूंढ रहा हूं - धन्यवाद एचएलजीईएम (और अन्य)। – Mayo

0

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

1

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

5

आपको आमतौर पर हाथ से कई स्थानों पर व्यवसाय नियमों को बनाए रखना बहुत मुश्किल लगेगा।

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

वही विचार मॉडल को अधिक जटिल नियमों के मॉडल तक बढ़ाया जा सकता है, और आवेदन की प्रत्येक परत में उपयुक्त प्रवर्तन कोड उत्पन्न कर सकता है।

+3

+1 "हाथ से कई स्थानों पर व्यवसाय नियमों को बनाए रखने में बहुत मुश्किल" के लिए +1। यह अक्सर भूल जाता है! – CesarGon

+1

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

5

व्यापार नियम या डेटा अखंडता नियम?

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

संबंधित मुद्दे