मुझे मेरी राय साझा करने दें।
सबसे पहले, मुझे लगता है कि आपके प्रश्न के वसंत बूट के साथ कुछ लेना देना नहीं है। स्प्रिंग बूट सिर्फ एप्लिकेशन शुरू करने के लिए एक फैंसी और हल्के तरीके प्रदान करता है और ऐप को एक आसान तरीके से बनाने की अनुमति देता है। लेकिन फिर भी आपके पास बाकी का नियंत्रक है और उस बिंदु से यह किसी अन्य प्रकार के एप्लिकेशन के लिए बहुत अलग नहीं है।
तो आप वास्तव में क्या पूछ रहे हैं कि क्या यह JSON ऑब्जेक्ट्स के एक अमूर्तता को बनाए रखने और उन्हें व्यवसाय तर्क इकाई वस्तुओं में परिवर्तित करने और बाद में डेटाबेस ऑब्जेक्ट्स में कनवर्ट करने या केवल 2 स्तरों को बनाए रखने के लिए पर्याप्त रूप से परिवर्तित करने के लिए समझ में आता है और जेसन स्तर को कुचलने।
मुझे लगता है कि उत्तर "यह निर्भर करता है"।
सबसे पहले, आम तौर पर प्रवृत्ति एक सरलीकरण है। तो शायद यह केवल 1 स्तर की वस्तुओं को बनाए रखने के लिए पर्याप्त है।
वहाँ इस तरह के दृष्टिकोण के लाभ का एक बहुत कुछ कर रहे हैं:
- जाहिर है कम कोड विकास के
- स्पीड और परीक्षण (POJOs जाँच की जानी चाहिए, कन्वर्टर्स परीक्षण किया जाना चाहिए और आगे) बनाए रखने के लिए
- निष्पादन की गति - आपको रूपांतरण पर CPU समय बर्बाद करने की आवश्यकता नहीं है। एक स्पष्ट निहितार्थ।
- कम स्पष्ट: मेमोरी खपत। आइए कहें कि आप अपने डीएओ द्वारा लौटाए गए डेटा के बड़े हिस्से के साथ काम करते हैं। मान लीजिए कि इसमें 10 एमबी मेमोरी है (केवल उदाहरण के लिए)। अब यदि आप बिजनेस एंटिटीज में कनवर्ट करना शुरू करते हैं, तो आप अभी तक एक और 10 एमबी खर्च करेंगे और अब अगर यह एक जेएसओएन ऑब्जेक्ट्स है, तो यह फिर से 10 एमबी है। मुद्दा यह है कि ये सभी वस्तुएं एक साथ स्मृति में सह-अस्तित्व में हो सकती हैं। निश्चित रूप से यदि आप सब कुछ सही तरीके से लागू करते हैं तो जीसी शायद उनका ख्याल रखेगी, लेकिन यह एक अलग कहानी है।
हालांकि इस तरह के एक सरलीकरण की कमी है।
एक शब्द में मैं इसे एक प्रतिबद्धता कहेंगे
आवेदन में एपीआई के तीन प्रकार के होते हैं।
एपीआई जो आप वेब सेवा के स्तर पर प्रतिबद्ध हैं - जेएसओएन संरचना। संभावना है कि विभिन्न ग्राहक (JVM का उपयोग करके आवश्यक नहीं) आपकी वेब सेवा के विरुद्ध चल रहे हैं और डेटा का उपभोग कर रहे हैं। इसलिए वे वास्तव में आपको दी गई संरचना के JSON ऑब्जेक्ट्स प्रदान करने की अपेक्षा करते हैं।
आपके व्यवसाय का एपीआई। यदि आपकी व्यावसायिक तर्क परत बहुत जटिल है, तो संभवतः आपके पास एक संपूर्ण टीम है जो उस तर्क को विकसित करती है। तो आप आमतौर पर टीमों के बीच एपीआई के स्तर पर काम करते हैं।
डीएओ का स्तर - वास्तव में व्यवसाय तर्क के समान कहानी।
तो अब, यदि आप कहते हैं कि क्या होता है, तो उस एपीआई को एक स्तर पर बदलें। क्या इसका मतलब है कि सभी स्तर टूट जाएंगे?
उदाहरण
कहते हैं, हम नहीं बनाए रखते हैं "JSON" स्तर की सुविधा देता है। इस मामले में, यदि हम बिजनेस लॉजिक के स्तर पर एपीआई बदलते हैं, तो JSON स्वचालित रूप से भी बदल जाएगा। सभी बाकी ढांचे खुशी से हमारे लिए वस्तु को परिवर्तित करेंगे, और संभावना है कि उपयोगकर्ता को एक और डेटा मिलेगा।
एक और उदाहरण
कहना चलें, अपने बीएल परत एक व्यक्ति इकाई है कि इस तरह दिखता है प्रदान करता है:
class Person {
String firstName;
String lastName;
List<Language> languages;
}
class Language {
...
}
अब मान लें कि आप एक यूआई कि आपके बाकी सेवा है कि एक प्रदान करता है खपत डालते हैं अनुरोध पर व्यक्तियों की सूची। यदि यूआई में 2 अलग-अलग पेज हैं तो क्या होगा। एक जो केवल व्यक्तियों को दिखाता है (इस मामले में किसी व्यक्ति द्वारा बोली जाने वाली भाषा की एक सूची प्रदान करने के लिए यह समझ में नहीं आता है)। दूसरे पृष्ठ में हालांकि आप पूरी जानकारी प्राप्त करना चाहते हैं।
तो, आप 2 वेब सेवाओं को उजागर कर सकते हैं या कुछ पैरामीटर द्वारा मौजूदा को जटिल बना सकते हैं (आपके जैसे अधिक पैरा, बाकी के जैसा ही कम है :)) शायद अलगाव थोड़ा सा मदद करेगा? मुझे नहीं पता।
नीचे पंक्ति। मैं कहूंगा कि जब तक आप इस तरह के अलगाव के बिना जी सकते हैं - ऐसा करें। यह काफी बड़ी परियोजनाओं के लिए भी काम कर सकता है। और निश्चित रूप से यह छोटे या मध्यम आकार की परियोजनाओं के लिए काम कर सकता है।
यदि आप स्वयं को फ़िक्स के आसपास संघर्ष करते हैं और आपको लगता है कि इस तरह के अलगाव मुद्दों को हल करेंगे - अलगाव करें।
उम्मीद है कि यह प्रभावों को समझने में मदद करता है और आपके लिए क्या काम करता है