स्प्रिंग/जेपीए/जेएसएफ

Question

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

हमारे आवेदन वास्तुकला नीचे की तरह है:

यूआई (JSF) -> प्रबंधित बीन्स -> सेवा -> डीएओ

हम डीएओ परत के लिए अपवाद अनुवाद सेम पोस्ट प्रोसेसर का उपयोग कर रहे हैं। यह स्प्रिंग एप्लिकेशन संदर्भ फ़ाइल में कॉन्फ़िगर किया गया है।

<bean class="org.springframework.dao.annotation.PersistenceExceptionTranslationPostProcessor" /> 

कहाँ स्प्रिंग 'org.springframework.dao.DataAccessException' करने के लिए सभी डेटाबेस अपवाद गिर्द घूमती है। हम डीएओ परत में कोई अन्य अपवाद हैंडलिंग नहीं कर रहे हैं।

हमारी रणनीति नीचे की तरह अपवाद को संभालने के लिए:

प्रस्तुति परत:

Class PresentationManangedBean{ 

try{ 
     serviceMethod(); 
    }catch(BusinessException be){ 
     // Mapping exception messages to show on UI 
    } 
    catch(Exception e){ 
     // Mapping exception messages to show on UI 
    } 

} 

सेवा लेयर

@Component("service") 
Class Service{ 

@Transactional(propagation = Propagation.REQUIRED, readOnly = false, rollbackFor = BusinessException.class) 
public serviceMethod(){ 

    try{ 

     daoMethod(); 

    }catch(DataAccessException cdae){ 
     throws new BusinessException(); // Our Business/Custom exception 
    } 
    catch(Exception e){ 
     throws new BusinessException(); // Our Business/Custom exception 
    } 
} 

} 

डीएओ लेयर

@Repository("dao") 
Class DAO{ 

public daoMethod(){ 
    // No exception is handled 
    // If any DataAccessException or RuntimeException is occurred this 
    // is thrown to ServiceLayer 
} 

} 

प्रश्न: हम सिर्फ ऊपर दृष्टिकोण सर्वोत्तम प्रथाओं के अनुसार है या नहीं इस बात की पुष्टि करना चाहते हैं। यदि नहीं, तो कृपया अपवादों को संभालने का सर्वोत्तम तरीका सुझाएं (लेनदेन प्रबंधन के साथ खेलना)?

Answer 1

यह दृष्टिकोण मेरे लिए अच्छा लग रहा है। हम अपने प्रोजेक्ट में एक ही तरह के दृष्टिकोण का उपयोग कर रहे हैं।

विनय

Answer 2

आपका दृष्टिकोण स्प्रिंग फ़्रेमवर्क सिफारिशों के अनुरूप बहुत ज्यादा है और यह भी अपने आवेदन की परतों में जांचे हुए अपवादों के बहुत सारे percolating बचा जाता है।

Answer 3

मैं एक अलग दृष्टिकोण का उपयोग करें:

मैं डीएओ में स्प्रिंग की डीएई को पकड़ने नहीं है। मैंने उन्हें नियंत्रक (जेएसएफ प्रबंधित बीन) तक जाने दिया।

- नियंत्रक में मैं किसी भी अपवाद को पकड़ता हूं (केवल एक "पकड़" के साथ)।

-I एक कस्टम "हैंडलएक्सप्शन" विधि को कॉल करता है जो पैरामीटर में पकड़ा अपवाद प्राप्त करता है।

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

मुझे लगता है कि यह दृष्टिकोण बेहतर और क्लीनर है, क्योंकि आपके पास केवल एक बिंदु में अपवाद हैंडलिंग है, और आपको नियंत्रक में प्रत्येक स्तर पर इतना "फेंकने की कोशिश" नहीं करना है (JSF)।

बेशक, आप विशेष अपवादों के लिए सेवाओं में "प्रयास-पकड़" का उपयोग कर सकते हैं, यदि आप उस विशेष मामले में क्या करना चाहते हैं तो उपयोगकर्ता को संदेश दिखाने के बजाय कुछ व्यावसायिक तर्क है।

और यदि आप नियंत्रक में स्प्रिंग डीएई से निपटना नहीं चाहते हैं, तो आप इसे अपने आप के व्यावसायिक अपवाद में लपेट सकते हैं और फिर से फेंक सकते हैं। लेकिन यह सेवा परत में करें, डीएओ में नहीं।

आशा है कि यह उत्तर मदद करेगा।

Answer 4

हो सकता है कि आप बिजनेसएक्सप्शन और बिजनेस रनटाइम अपवाद, को अलग कर सकें क्योंकि जब आप BusinessException को BusinessException फेंकते हैं, लेकिन जब आप अपवाद प्राप्त करते हैं तो भी आप वही व्यवसाय अपवाद फेंकते हैं। उन्हें separete करने की कोशिश करो। जब आप BusinessException को पकड़ते हैं तो वैसे ही आप एक ही अपवाद क्यों फेंकते हैं?

Answer 5

मैं कुछ शोध कर रहा था क्योंकि मैं स्वयं इस पर उलझन में था। हालांकि मेरे पास थोड़ा अलग लेना है।

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

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

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

Class PresentationManangedBean{ 
     try { 
     Response resp1 = serviceMethod(); 
     if (resp1.getStatus().equals("SUCCESSFUL")) 
      // handle UI painting logic. 
     else 
      // handle error for UI 
     Response resp2 = serviceMethod2(); 
     if (resp.getStatus().equals("SUCCESSFUL")) 
      // handle UI painting logic. 
     else 
      // handle error for UI 
     // handle resp1 and resp2 to paint UI. 
    } catch (Exception e) { 
      // handle error for UI 
    } 
} 

1) सेवा सभी अपवादों को संभालना चाहिए। नियंत्रक को किसी भी अपवाद को संभालना नहीं चाहिए। 2)