सत्यापन किस परत में स्थित होना चाहिए?

Question

मैं स्प्रिंग बूट का उपयोग करके एक रेस्ट एपीआई बना रहा हूं और मैं अनुरोध निविष्टियों को मान्य करने के लिए हाइबरनेट सत्यापन का उपयोग कर रहा हूं।

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

क्या यह सत्यापन सेवा परत या नियंत्रक परत पर स्थित होना चाहिए?

सेवा परत:

 public Company update(Company entity) {
    if (entity.getId() == null || repository.findOne(entity.getId()) == null) {
        throw new ResourceNotFoundException("can not update un existence data with id : " 
            + entity.getId());
    }
    return repository.saveAndFlush(entity);
}

नियंत्रक परत:

public HttpEntity<CompanyResource> update(@Valid @RequestBody Company companyRequest) {
    Company company = companyService.getById(companyRequest.getId());
    Precondition.checkDataFound(company, 
        "Can't not find data with id : " + companyRequest.getId());

    // TODO : extract ignore properties to constant

    BeanUtils.copyProperties(companyRequest, company, "createdBy", "createdDate",
            "updatedBy", "updatedDate", "version", "markForDelete");
    Company updatedCompany = companyService.update(company);
    CompanyResource companyResource = companyAssembler.toResource(updatedCompany);
    return new ResponseEntity<CompanyResource>(companyResource, HttpStatus.OK);
}

Answer 1

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

अब, आपका सत्यापन अनिवार्य रूप से नियंत्रक अद्यतन () विधि और सेवा परत अद्यतन () विधि के अनुबंध का प्रवर्तन है। दोनों का अनुबंध बहुत समान है इसलिए यह स्वाभाविक होगा यदि सत्यापन (अनुबंध का प्रवर्तन) भी सामान्य होगा।

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

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

इस डिजाइन में, सर्विस लेयर में बिजनेस लॉजिक के बीच बहुत अधिक कपलिंग का खतरा है (जो कि काफी सामान्य होना चाहिए) और कंट्रोलर (जो एकीकरण लॉजिक को हैंडल करता है)।

वैसे भी, यह काफी विवादास्पद सवाल है और 100 जवाब के साथ 100 लोग जवाब देंगे। यह सिर्फ मेरा लेना है।

Answer 2

इनपुट सेवा परत में जाँच की जानी चाहिए।

और "id नहीं पा सकते" तार्किक त्रुटि स्थिति है। तो नियंत्रक परत से फेंक दिया जाना चाहिए।

यह फिर से आपके लेयरिंग / डिज़ाइन पर निर्भर करता है।
सेवा परत को क्या करना चाहिए और नियंत्रक परत से क्या अपेक्षा की जाती है।

Comments

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

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

— जस्टमार्टिन

Answer 3

हाइबरनेट सत्यापन डेटा की अखंडता पर जाँच है । आदेश में bbdd से RuntimeException से बचने के लिए। वे काफी हद तक वही मान्यताएं हैं जिन्हें आपको कॉन्स्ट्रेन्स के साथ नियंत्रित करना चाहिए । चूँकि केवल व्यवसायिक परत ही दृढ़ता परत को खिलाने वाली होनी चाहिए , आप अपनी व्यावसायिक परत से आने वाले डेटा की शुद्धता पर विश्वास कर सकते हैं (या नहीं, आप पर निर्भर है)

मैं डीएओ में सत्यापन नहीं करता हूं। मुझे ऊपरी परतों से वैध डेटा की उम्मीद है। एक त्रुटि के मामले में मैं इसकी सामग्री के बारे में पता करने के लिए ज़िम्मेदारी बीबीडी को सौंपता हूं।

फिर व्यावसायिक स्तर पर सत्यापन आता है। सभी व्यावसायिक सत्यापन डेटा की सुसंगतता को ध्यान में रखते हैं , न कि इसकी अखंडता पर ।

अंत में मैं नियंत्रण परत पर पिछले सत्यापन करता हूं। जिनका संबंध केवल ऐसी परत से है।

आप जल्द ही देखेंगे कि किन मान्यताओं का उद्देश्य व्यावसायिक स्तर पर लगाया जाना है। सबसे आम: आईडी नियंत्रण। यह आसानी से दोनों परतों पर लागू किया जा सकता है। यदि आपको कई नियंत्रकों या क्लाइंट से आपके व्यवसाय की परत का उपभोग करने की उम्मीद है, तो हर जगह एक ही मान्यता को दोहराने के बजाय, यह व्यवसाय की परत पर रखा जाने वाला एक उत्कृष्ट उम्मीदवार होगा।

कभी-कभी नियंत्रकों के अपने नियम और शर्तें होती हैं जिन्हें किसी अन्य पहलू में पुन: प्रस्तुत नहीं किया जाता है। फिर इसे ऐसे नियंत्रक में रखा जाना है।

इस बारे में सोचें कि आप किसके लिए मान्य हैं और यदि आप इसे सभी के लिए लागू करना चाहते हैं, तो कोई बात नहीं। या यदि यह एक प्रासंगिक मान्यता है ("इम किसी चीज़ को मान्य करता है जो केवल एक विशेष नियंत्रण / दृश्य मुखौटा पर होता है)।

Answer 4

हमारे जावा शॉप में, हमने तीन अलग-अलग ऑपरेशनों पर जानबूझकर वेब विजेट सत्यापन को विभाजित किया है।

1. मूल स्वरूपण - संख्या संख्या होनी चाहिए; तिथियां मान्य तिथियां आदि होनी चाहिए। आमतौर पर यह सत्यापन मुफ्त में होता है - वेब फ्रेमवर्क मॉडल के लिए बाध्यकारी होने पर आपके लिए इसे करेगा।
2. एकल विजेट सत्यापन - तारीख अतीत में होनी चाहिए; पूर्णांक 1 और 100 के बीच होना चाहिए; customerId को डेटाबेस आदि में मौजूद होना चाहिए। यह ज्यादातर मामलों में कंट्रोलर लेयर में होता है, लेकिन इसे डेटा रिपॉजिटरी से समर्थन की आवश्यकता हो सकती है।
3. क्रॉस-विजेट सत्यापन - चेकआउट की तारीख चेक-इन की तारीख के बाद होनी चाहिए; मृत्यु की तारीख जन्म तिथि आदि से पहले नहीं हो सकती। यह निश्चित रूप से व्यावसायिक नियम मान्यता है। हम इसे नियंत्रक परत में भी डालते हैं, लेकिन आप इसे व्यवसाय सत्यापनकर्ता में स्थानांतरित करना चाहते हैं, इसलिए इसका पुन: उपयोग किया जा सकता है।

यदि लेयर 1 विफल हो जाता है, तो हम 2 या 3 की जांच नहीं करते हैं। इसी तरह यदि 1 सफल होता है और 2 विफल होता है, तो हम 3 नहीं करते हैं। यह स्पार्टियस एरर मैसेज को उत्पन्न होने से रोकता है।

आप विजेट सामग्री के बजाय REST कॉल में मूल्यों के बारे में पूछ रहे हैं, लेकिन वही सिद्धांत लागू होते हैं।

Answer 5

टेस्ट संचालित aproach शेड इस पर प्रकाश डालता है, आखिरकार कोई नियंत्रक नहीं है और आपको एक अन्य विकल्प चुनना होगा। स्पष्ट रूप से bussines नियम एक ही स्थान पर होने चाहिए, और यह आपके पतन में एक और अड़चन है।