आपको अपने REST API में DTO का उपयोग क्यों करना चाहिए
DTO का मतलब D ata T ransfer O bject है ।
यह पैटर्न बहुत अच्छी तरह से परिभाषित उद्देश्य के साथ बनाया गया था: वेब सेवाओं की तरह, डेटा को दूरस्थ इंटरफेस में स्थानांतरित करना । यह पैटर्न एक REST एपीआई में बहुत अच्छी तरह से फिट बैठता है और डीटीओ आपको अधिक लचीलापन देगा लंबे समय में ।
मॉडल का प्रतिनिधित्व डोमेन आपके आवेदन की और मॉडल है कि प्रतिनिधित्व डेटा अपने एपीआई के द्वारा नियंत्रित कर रहे हैं (या कम से कम होना चाहिए) विभिन्न चिंताओं और किया जाना चाहिए decoupled एक दूसरे से। जब आप एप्लिकेशन डोमेन मॉडल से किसी फ़ील्ड को जोड़ते हैं, हटाते हैं या उसका नाम बदलते हैं, तो आप अपने API क्लाइंट को नहीं तोड़ना चाहते।
जब आपकी सेवा परत डोमेन / हठ मॉडल पर काम करती है, तो आपके एपीआई नियंत्रकों को विभिन्न मॉडलों के सेट पर काम करना चाहिए। जैसा कि आपके डोमेन / दृढ़ता मॉडल नई व्यावसायिक आवश्यकताओं का समर्थन करने के लिए विकसित होते हैं, उदाहरण के लिए, आप इन परिवर्तनों का समर्थन करने के लिए एपीआई मॉडल के नए संस्करण बनाना चाह सकते हैं। नए संस्करण जारी होते ही आप अपने एपीआई के पुराने संस्करणों को भी हटाना चाहेंगे। और यह पूरी तरह से संभव है जब चीजें डिकम्पोज की जाती हैं।
दृढ़ता मॉडल के बजाय डीटीओ को उजागर करने के कुछ लाभों का उल्लेख करने के लिए:
एपीआई मॉडल से वास्तविक दृढ़ता मॉडल।
डीटीओ आपकी आवश्यकताओं के अनुरूप हो सकते हैं और आपकी दृढ़ता संस्थाओं की विशेषताओं के एक सेट को उजागर करते समय वे महान होते हैं। आप इस तरह के रूप में एनोटेशन की जरूरत नहीं होगी @XmlTransientऔर @JsonIgnoreकुछ विशेषताओं की क्रमबद्धता से बचने के लिए।
डीटीओ का उपयोग करके, आप अपनी दृढ़ता संस्थाओं में एनोटेशन के एक नरक से बचेंगे , अर्थात, आपकी दृढ़ता संस्थाओं को गैर-दृढ़ता से संबंधित एनोटेशन के साथ फूला नहीं होगा।
संसाधन बनाते या अद्यतन करते समय आपको प्राप्त होने वाली विशेषताओं पर आपका पूर्ण नियंत्रण होगा ।
यदि आप स्वैगर का उपयोग कर रहे हैं , तो आप अपनी दृढ़ता मॉडल को गड़बड़ाने के बिना अपने एपीआई मॉडल का दस्तावेजीकरण करने के लिए उपयोग @ApiModelऔर @ApiModelPropertyएनोटेशन कर सकते हैं ।
आपके एपीआई के प्रत्येक संस्करण के लिए अलग-अलग डीटीओ हो सकते हैं।
संबंधों को मैप करते समय आपके पास अधिक लचीलापन होगा।
विभिन्न मीडिया प्रकारों के लिए आपके पास अलग-अलग डीटीओ हो सकते हैं।
आपके डीटीओ के पास HATEOAS के लिंक की सूची हो सकती है । यह उस तरह की चीज है जिसे दृढ़ता वस्तुओं में नहीं जोड़ा जाना चाहिए। स्प्रिंग हेटोस का उपयोग करते समय , आप अपने डीटीओ वर्गों को विस्तार RepresentationModel(पहले के रूप में जाना जाता है ResourceSupport) कर सकते हैं या उन्हें EntityModel(पहले के रूप में जाना जाता है Resource<T>) के साथ लपेट सकते हैं ।
बॉयलरप्लेट कोड के साथ काम करना
आप विपरीत DTOs और उपाध्यक्ष के लिए अपने हठ संस्थाओं को मैप करने की जरूरत नहीं होगी mannually । रहे हैं कई मानचित्रण चौखटे आप यह करने के लिए उपयोग कर सकते हैं। उदाहरण के लिए, MapStruct पर एक नज़र है , जो एनोटेशन आधारित है और मावेन एनोटेशन प्रोसेसर के रूप में काम करता है। यह सीडीआई और स्प्रिंग-आधारित दोनों अनुप्रयोगों में अच्छा काम करता है।
आप यह भी विचार कर सकते हैं लंबोक उत्पन्न करने के लिए ही टिककर खेल, setters, equals(), hashcode()और toString()आप के लिए तरीके।
संबंधित: अपने डीटीओ वर्गों को बेहतर नाम देने के लिए, इस उत्तर को देखें ।