सेवा

Question

के माध्यम से जेपीए इकाइयों का खुलासा करना हम AngularJS, Rest, JPA के साथ एक वेब अनुप्रयोग विकसित करने की प्रक्रिया में हैं। मैंने कुछ लेख पढ़े हैं कि डोमेन इकाइयों को सेवाओं के माध्यम से कैसे उजागर नहीं किया जाना चाहिए। मैं समझता हूं कि यह तंग युग्मन है, परिपत्र संदर्भ हो सकते हैं, चिंताओं को अलग किया जा सकता है और यह मेरे लिए मान्य लगता है। लेकिन फिर मैं एक ही मॉडल में जेपीए और जैक्सब मैपिंग्स को लागू करने के बारे में आलेख देखता हूं, ग्रहण लिंक एक उदाहरण है।

तो फिर वहाँ वसंत डेटा बाकी जो एक आराम एपीआई के माध्यम से जेपीए संस्थाओं को उजागर करता है। (हो सकता है वसंत डाटा बाकी हाथ में एक अलग समस्या को हल करने के लिए इस्तेमाल किया जाता है)

तो मैं एक छोटा सा उलझन में हूँ। निम्नलिखित 2 प्रश्नों और परिदृश्यों का उत्तर जहां एक बेहतर है कि दूसरा सहायक होगा।

1. उसी डोमेन मॉडल में जैक्सबी और जेपीए एनोटेशन दोनों को लागू करने के क्या फायदे हैं? क्या यह मुख्य रूप से परतों के बीच एक डीटीओ से बचने के लिए किया जाता है?

2. वसंत चाहिए डेटा बाकी केवल इस्तेमाल किया जा है जब आप एक आवेदन जो CRUD संचालन का पर्दाफाश करने की जरूरत है और वास्तव में कोई अन्य व्यवसाय कार्यक्षमता शामिल है विकसित कर रहे हैं?

Answer 1

डीटीओ का उपयोग करने के लिए एक निश्चित ओवरहेड की आवश्यकता होती है: डीटीओ कक्षाएं बनाई जानी चाहिए; सीरियलाइजेशन से पहले इकाई वर्गों को डीटीओ में मैप किया जाना चाहिए।

डीटीओ अब तक "गलत महसूस करें" जैसा कि वे "खुद को दोहराएं" सिद्धांत का उल्लंघन नहीं करते हैं। एक इकाई और डीटीओ को देखना निराशाजनक है और देखें कि वे अनिवार्य रूप से वही हैं।

तो, सीधे अपनी जेपीए इकाइयों को उजागर करने से कोड कम हो जाता है और कोड के साथ काम करते समय मानसिक ओवरहेड कम हो जाता है। आपके नियंत्रक, सेवाएं, और भंडार सभी एक ही कक्षा के साथ सौदा करते हैं।

वहाँ मुद्दे हैं लेकिन:

अपने आंतरिक अभ्यावेदन और इंटरफ़ेस के बीच

• बेमेल आप एपीआई उपयोगकर्ता को बेनकाब करना चाहते हैं।

  असली दुनिया का उदाहरण: पदानुक्रमित दस्तावेज़ जिसमें रूट दस्तावेज़ article है और बाल दस्तावेज़ sections हैं। आंतरिक रूप से, प्रत्येक दस्तावेज़ का एक मूल दस्तावेज़ से संबंध होता है जो शून्य हो सकता है।

  बाकी इंटरफेस के माध्यम से सीधे इस इकाई को प्रकाश में लाने के लिए अपने प्रस्तुत किए गए दस्तावेजों को एक साथ सही ढंग से लिंक करने के लिए इकाई के हिस्से के रूप id (या HATEOAS में url) भेजने के लिए ग्राहक की आवश्यकता होगी।

  उपधारा बनाने के दौरान एपीआई उपयोगकर्ता पोस्ट /articles/{id}/sections/ पर बेहतर है।

• आंतरिक डेटा का खुलासा।

  आपका संस्थाओं पहचानकर्ता, डिस्क पर पथ, आदि जो जनता के उपभोग के लिए वास्तव में नहीं हैं शामिल हो सकते हैं। धारावाहिक करते समय आपको @JsonIgnore करना होगा। जब deserializing, तो आप भी हाथ से इकाई से भरेंगे।

• प्रदर्शन।

  उपरोक्त बिंदु के समान; हो सकता है कि आपकी इकाई में एक बड़ी डेटा ऑब्जेक्ट हो। आप चाहते हैं कि उपयोगकर्ता इन्हें पोस्ट या PUT करने में सक्षम हों, लेकिन उन्हें इकाई के अन्य फ़ील्ड को पढ़ने के लिए ऑब्जेक्ट को डाउनलोड करने की आवश्यकता नहीं होनी चाहिए।

• संभावित क्रमिकरण मुद्दे।

  आलसी लोड संग्रह यहां क्लासिक विफलता मामले हैं।

• आवश्यक से अधिक जटिल क्रमबद्ध प्रतिनिधित्व।

  असली दुनिया का उदाहरण: इकाई synonyms के संग्रह के साथ इकाई; समानार्थी शब्द पर निर्भर हैं। सीधे संस्थाओं serializing परिणाम देगा में:

  { "id":12, 
      "word": "cat", 
      "synonyms": [ 
      { "id": 23, 
       "synonym": "kitty" 
      }, 
      { "id": 34, 
       "synonym": "pussycat" 
      } 
      ] 
  } 
  

  एक बेहतर मॉडल है: एक ही कक्षा जो स्पष्टता को कम कर सकते एनोटेशन से

  { "word": "cat", 
      "synonyms": [ 
      "kitty", 
      "pussycat" 
      ] 
  } 
  

• बहुत सारे।

  अपने इकाई जटिलता के आधार पर, आप जेपीए एनोटेशन (@Entity, @Id, @GeneratedValue, @Column, @ManyToMany, @MappedBy, आदि), एक्सएमएल एनोटेशन (@XmlRootElement, @XmlType, @XmlElement, आदि), JSON एनोटेशन (@JsonInclude, @JsonIgnore हो सकता है, @JsonProperty, आदि), और सत्यापन एनोटेशन (@NotNull, @Null, आदि) सभी एक ही कक्षा में।

इन सभी मुद्दों के कारण, मैं आम तौर पर डीटीओ का उपयोग करता हूं। मैं हाथ से डीटीओ मैपिंग की इकाई करता हूं, लेकिन ऐसी परियोजनाएं हैं जो इसे आसान बनाने की कोशिश करती हैं, जैसे Dozer।

मैं spring-data-rest का उपयोग करके कल्पना कर सकता हूं या केवल मेरी स्थिति को उजागर कर सकता हूं, जहां मेरे पास बहुत सरल संस्थाएं हैं, उनके बीच बहुत से संबंध हैं, और जहां इकाई मॉडल और मॉडल के बीच उच्च पत्राचार है जहां मैं कामना करता हूं उपयोगकर्ता को बेनकाब करें।