सेवा परत

Question

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

वही सवाल यूआई परत से निपटने अपवाद सेवा परत द्वारा फेंका लिए लागू है।

Answer 1

जब हम एक स्तरित आवेदन बनाने के लिए, वहाँ हमेशा एक उपयोगकर्ता परत और एक अन्य इस्तेमाल किया परत है। इस मामले के लिए यूआई परत -> सेवा परत का उपयोग करता है -> डीएओ परत का उपयोग करता है।

अब अपने बहुत व्यक्तिपरक और व्याख्याओं के लिए खुला। लेकिन उद्देश्य decoupling की अच्छी डिग्री होना चाहिए। इसे प्राप्त करने के लिए, एक तरीका बाहर जेनेरिक परत विशिष्ट अपवादPersistentException, ServiceException आदि परिभाषित करता है। ये अपवाद वास्तविक परत विशिष्ट अपवाद को लपेटेंगे।

उदाहरण के लिए कहते हैं कि अगर वहाँ (आदि बाधा उल्लंघन) डेटाबेस पक्ष पर कुछ त्रुटि है, लपेट PersistentException में कि और सेवा परत है कि संभाल

(कैसे एक सामान्य तरीके यूआई परत को यह संप्रेषित करने के लिए करने के लिए के रूप में) जाने

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

Answer 2

अच्छा सवाल .. !! UI परत पर अपवादों को संभालना (उदाहरण के लिए, यदि आप स्ट्रेट्स का उपयोग कर रहे हैं तो क्रिया परत) अच्छा दृष्टिकोण है। जेनेरिक अपवाद सामान्य रूप से इस समस्या से निपटने का एक अच्छा तरीका नहीं है। प्रत्येक परत को सामान्य के रूप में उनके विशिष्ट अपवाद होना चाहिए। उदाहरण के लिए, डीएओ परत में कस्टम अपवाद हैंडलर जैसे डेवासेविंग अपवाद, आईओएक्सप्शन इत्यादि हो सकते हैं ..

तो दृष्टिकोण डीएओ से सर्विस लेयर में अपवाद फेंक दिया गया है और फिर इसे यूआई परत पर फेंक दिया गया है और यूआई विशिष्ट कक्षाओं में पकड़ लिया गया है।

हालांकि चीजें बहुत राजनयिक अपने अनुप्रयोगों/जरूरतों के आधार पर कर रहे हैं।

Answer 3

हां। प्रत्येक परत के लिए अपने स्वयं के स्वतंत्र अपवाद बनाने का एक अच्छा विचार है।

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

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

इस तरह कुछ ऐसा कार्यान्वयन विशिष्ट अपवाद अनुकरण करने और सेवा परत पर फेंकने के लिए उपयोग किया जा सकता है।

class AppDAOException extends Exception { 
    public final static int _FAIL_TO_INSERT = 1; 
    public final static int _UPDATE_FAILED = 2; 
    public final static int _SQL_ERROR = 3; 
    private int errorCode; 
    public AppDAOException(int errorCode) { 
     this.errorCode = errorCode; 
    } 
    public getErrorCode() { 
     return errorCode; 
    } 
} 

डीएओ कार्यान्वयन से फेंकने:

try { 
    //code here 
} catch (some.impl.SQLSyntaxException e) { 
    throw new AppDAOException (AppDAOException._SQL_ERROR); 
} 

चिंता का रिसाव के बारे में: आप अपनी सेवा परत सभी अपवादों के बारे में परेशान करने के लिए नहीं चाहते हो सकता है - जैसे:

} catch(NoRowExistsException e) { 
    return null; 
} finally { 
    //release resources 
} 

तो आवेदन की जरूरतों के आधार पर कॉल लेना है।

Answer 4

आपका डीएओ परत पहले से ही सेवा परत में लीक जब आप जैसे कार्य करते हैं:

userDAO.persist(user); 

अपवाद, एपीआई आपरेशन जैसे एक ही तरह से विचार किया जाना चाहिए का एक हिस्सा होने।

try { 
    userDAO.persist(user); 
} catch (DAOException e) { 
    // looks fine to me 
} 

रिसाव क्रम अपवादों के साथ भी हो सकता है, या जब आप अपवाद

try { 
    userDAO.persist(user); 
} catch (SQLException e) { 
    // sql implementation exposed 
} 

rethrow लेकिन फिर भी इससे बेहतर लगता है "परत स्वतंत्र" अपवाद जवाब के लिए