हालांकि मैं नहीं कह सकता कि टीम द्वारा निर्णय क्यों लिया गया, मैं पूरी तरह से सहमत हूं कि डीटीओ/वीएम-अवधारणा बहुत स्पष्ट नहीं है।
मुझे लगता है कि मूल विचार एमवीपी/एमवीसी पैटर्न के अनुरूप था जहां अक्सर एमवीवीएम पैटर्न प्राप्त करने के लिए एक नया व्यू-मॉडल पेश किया जाता है। इसलिए डीटीओ जो किसी भी दृश्य को प्रभावित नहीं करते हैं उन्हें वास्तविक मॉडल/नियंत्रक परत में "धक्का" दिया जाता था। जो ठीक है, अगर आप कहते हैं कि एक डीटीओ सेवाओं के बीच स्थानांतरण-वस्तु है।
हालांकि, हमारे पास हमारे पुराने जिप्स्टर-एप में परतों और डीटीओ, वीएम और इतने पर भी "परेशानी" और कई चर्चाएं थीं। हमने उसी समय शुरुआत की जब जिप्स्टर ने डीटीओ और मैपस्ट्रक्चर सामान पेश किए। नई परियोजनाओं में, जहां हम जिप्स्टर का उपयोग करते हैं, हम हमेशा सभी डीटीओ और वीएम को हटा देते हैं। सबसे पहले: (प्रबंधित) उपयोगकर्ता नाम/डीटीओ सामान, जो बहुत भ्रमित है। इसके कई कारण हैं:
हमारे पास हमारे अनुप्रयोगों के सर्वर-पक्ष में कभी भी वीएम नहीं है। एक jhipster आवेदन में, जहां दृश्य पूरी तरह से जावास्क्रिप्ट/कोणीय पर आधारित है, दृश्य मॉडल वहां होना चाहिए। हमारे पास अक्सर अन्य एप्लिकेशन होते हैं जो आरईएसटी-एपीआई का उपयोग करते हैं और ये एप्लिकेशन दृश्य नहीं हैं। इसलिए, विशेष रूप से एक माइक्रोस्कोस-आर्किटेक्चर में, मैं कभी भी आरईएसटी-एपीआई "व्यू" या यहां तक कि "व्यू-मॉडल" में कुछ भी नहीं कहूंगा। इस प्रकार, ऐसे अनुप्रयोगों में जहां जावा में कोई दृश्य नहीं लिखा गया है (जेएसपी या तो), आपको हमारे जावा कोड में "वीएम" शब्द कभी नहीं मिलेगा। इसके अलावा, विभिन्न प्रकार के विचार हो सकते हैं (जैसे कोणीय वेब-ऐप, आईओएस ऐप, डेस्कटॉप क्लाइंट या अन्य चीजें) और उनमें से प्रत्येक के पास अन्य विचार हैं, पार्ट्स, विगेट्स देखें और इसलिए अन्य व्यू-मॉडलों की आवश्यकता है। अंत में, कुछ लोग थे जो कहते हैं कि आरईएसटी-एपीआई ऐसी कोई भी सामग्री प्रदान नहीं कर सकती जो वास्तविक संसाधन/इकाई नहीं है ...
तो, आप बिल्कुल सही है कि jhipster में VMs तथ्य DTOs में कर रहे हैं। लेकिन, जैसा कि आप यह भी कहते हैं, "डीटीओ" में कोई समस्या है, क्योंकि आम तौर पर एक डीटीओ दो या दो से अधिक सेवाओं (या सिस्टम) के बीच किसी भी तर्क के बिना सामान्य मूल्यों को समाहित करने के लिए एक स्टेटलेस ट्रांसफर ऑब्जेक्ट होता है। हमें लगता है कि यह टॉप-डाउन (आरईएसटी) एपीआई संचालित और नीचे-अप डोमेन-संचालित डिज़ाइन के बीच एक वास्तुशिल्प समस्या है, जो कि किसी भी तरह जेएचप्स्टर ऐप्स में मिश्रित है। आपकी राय के समान, मुझे लगता है कि जेएचप्स्टर डीटीओ का उपयोग करता है जहां यह एक डोमेन ऑब्जेक्ट (या एक इकाई) होना चाहिए। जैसे एक प्रबंधित उपयोगकर्ता वीएम या डीटीओ नहीं है, यह एक इकाई है। मुझे लगता है कि यहां समस्या यह है कि कुछ लोग सोचते हैं कि केवल जेपीए-आधारित इकाइयां डोमेन ऑब्जेक्ट्स हैं और कोई अन्य डोमेन ऑब्जेक्ट्स (संस्थाएं) नहीं हो सकती हैं।
अंत में, हम, एडीओ (एपीआई डेटा ऑब्जेक्ट या एक्सेस डेटा ऑब्जेक्ट) नामक एक नए प्रकार लागू करने के लिए तय है क्योंकि हम कोई शब्द है कि फिट बैठता है पाया। एक एडीओ की तुलना एक वीएम, एक डीटीओ या यहां तक कि एक इकाई के बिना किसी तर्क के जिप्स्टर से की जाती है। एक आम "एपीआई-लेयर" केवल एडीओ पढ़ता है और लिखता है। इस परत का उपयोग आरईएसटी एपीआई नियंत्रकों के साथ-साथ जावा एपीआई के लिए किया जाता है जिसे प्लगइन द्वारा उपयोग किया जा सकता है। यह हमें किसी भी विशिष्ट आंतरिक संस्थाओं या डोमेन ऑब्जेक्ट्स को जोड़ने के बिना क्लाइंट-एपीआई-जार के साथ सभी एडीओ को शिप करने की संभावना देता है। चूंकि आरईएसटी-एपीआई और प्रत्येक प्लगइन एक ही एडीओ (और इसलिए वही विवरण और संरचना) का उपयोग करता है, डेवलपर्स भ्रमित नहीं होते हैं और बाहरी संसाधन-उन्मुख परतों को आंतरिक परतों से ठीक से अलग किया जाता है जो संसाधनों की तुलना में किसी अन्य व्यावसायिक तर्क का उपयोग करते हैं- आधारित।
बाकी सब कुछ है कि संस्थाओं, व्युत्पन्न संस्थाओं, सबसेट या संस्थाओं का supersets की तरह आंतरिक परत का हिस्सा है ज्यादातर डोमेन वस्तुओं रहे हैं। इसलिए हमने इस आंतरिक परत, व्यापार तर्क आदि से सभी वीएम और डीटीओ को हटा दिया।
संक्षेप में: बाहरी पहुँच से आंतरिक (जेपीए) संस्थाओं को संपुटित के लिए, हम ADOS उपयोग करते हैं, के बाद से वहाँ सिर्फ विचारों से दूसरों हो सकता है। ये एडीओ जिप्स्टर वीएम के साथ-साथ डीटीओ के मामले में हैं। लेकिन आंतरिक एपीआई परत के अंदर आंतरिक रूप से, हम कभी भी किसी भी डीटीओ या वीएम या यहां तक कि एडीओ का उपयोग नहीं करते हैं, क्योंकि वे संस्थाएं ज्यादातर डोमेन ऑब्जेक्ट्स होती हैं।
इस तरह के एक विस्तार से VMs/DTOs करने के लिए अपने दृष्टिकोण descibing के लिए धन्यवाद। मैं आपको निर्णय समझ सकता हूं और सोच सकता हूं कि एडीओ एक बहुत अच्छा दृष्टिकोण है। विशेष रूप से, जब आपके पास न केवल ग्राहक के रूप में दृश्य होता है। –
सामान्य रूप से जेएचप्स्टर के रूप में यूआई समेत एक आवेदन की पूरी मचान के लिए इरादा है, मुझे लगता है कि वीएम एक ऐसा शब्द है जो इसके लिए उपयुक्त है। लेकिन वैसे भी, मुझे लगता है कि विशेष रूप से नए डीटीओ भाग को दस्तावेज में और स्पष्ट किया जाना चाहिए या जेएचप्स्टर में आगे अनुकूलित किया जाना चाहिए। यह है, अगर JHipster टीम ने डीटीओ/वी एम रिफैक्टरिंग में शामिल किया गया था से किसी को कुछ अंतर्दृष्टि :) –
मैं इस लिंक वे अपने नजरिए समझाया में लगता है कि दे सकता है, हालांकि मुझे लगता है कि एडीओ एक अधिक परिपक्व समाधान है बहुत अच्छा होगा: https: //jhipster.github.io/2016/08/17/jhipster-release-3.6.0.html –