रिपोजिटरी में कैच करने का प्रयास करें

Question

रिपोजिटरी पैटर्न के लिए मैंने जो भी उदाहरण देखा है, उनमें कोई भी त्रुटि प्रबंधन शामिल नहीं है। यह क्यों है? उदाहरण के लिए कहें कि मेरे पास यह है:

public virtual TItem Insert<TItem>(TItem item) where TItem:class,new() 
    { 
     dbContext.Set<TItem>().Add(item); 
     try 
     { 
      dbContext.SaveChanges(); 
     } 
     catch (DbUpdateException) 
     { 

      return null; 
     } 

     return item; 

    } 

एक उदाहरण जहां हम बाधा का उल्लंघन करते हैं। मैं DbUpdateException को पकड़ता हूं ... भंडार में नहीं होने पर यह त्रुटि लाइव हो सकती है?

Answer 1

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

उदाहरण के लिए, मान लें कि हम भंडार के माध्यम से एक रिकॉर्ड डालना चाहते हैं और फिर नई आईडी प्रिंट करना चाहते हैं। मान लें कि डालने किसी भी कारण से असफल होने जा रहा है।

var myNewItem = myRepository.Insert(myItem); 
Console.WriteLine("MyItem added with ID: {0}", myNewItem.ID); 

अपने प्रश्न में पैटर्न के बाद, आप एक NullReference अपवाद दूसरी पंक्ति पर अगर Insert विफल रहता है मिल चाहते हैं। यह थोड़ा अजीब है। पहली पंक्ति पर DbUpdateException को देखना अधिक स्पष्ट है। Insert पर हमेशा गिनने में सक्षम होना बेहतर है या तो एक वैध उदाहरण लौटा रहा है या अपवाद फेंकना बेहतर है।

Answer 2

एक उचित ढंग से डिज़ाइन किए गए सिस्टम में, बाधाओं का उल्लंघन कभी नहीं किया जाना चाहिए। अपनी संस्थाओं को बेहतर बनाएं: उदाहरण के लिए, अंधेरे ऑटो-कार्यान्वित सेटर्स का उपयोग न करें।

भंडार डेटा सत्यापन करने की जगह नहीं है। उचित स्थान है:

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

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