क्या मुझे जीडब्ल्यूटी एप्लिकेशन

Question

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

मैं विकल्प ए का उपयोग करना चाहिए: GWT-RPC और ऐप्लिकेशन का निर्माण जल्दी से

विकल्प बी: वसंत MVC 3.0 @Repository एनोटेशन का उपयोग सभी महान @Controller, @Service, के साथ एक बाकी बैकएंड निर्माण और निर्माण एक जीडब्ल्यूटी ओवरले फीचर्स और जीडब्ल्यूटी अनुरोध निर्माता का उपयोग करके बैकएंड से बात करने के लिए क्लाइंट साइड लाइब्रेरी?

मुझे इस प्रकार के डिज़ाइन के साथ सभी पेशेवरों और विपक्षों और लोगों के अनुभवों में रूचि है?

Answer 1

अपने आप से सवाल पूछें: "क्या मुझे गैर-जीडब्ल्यूटी फ्रंट फ्रंट के साथ सर्वर-साइड इंटरफ़ेस का पुन: उपयोग करने की आवश्यकता होगी?"

अगर जवाब है "नहीं, मैं सिर्फ एक GWT ग्राहक होगा": आप GWT-RPC का उपयोग कर सकते है, और वास्तव का लाभ लेने के आप अपने जावा सर्वर और ग्राहक पर दोनों वस्तुओं का उपयोग कर सकते है कि साइड। यह संचार को थोड़ा अधिक कुशल बना सकता है, कम से कम जब <inherits name="com.google.gwt.user.RemoteServiceObfuscateTypeNames" /> के साथ उपयोग किया जाता है, जो प्रकार के नामों को छोटे संख्यात्मक मानों तक छोटा करता है। आपको बेहतर त्रुटि प्रबंधन (अपवादों का उपयोग करके) का लाभ भी मिलेगा,

यदि उत्तर है "हाँ, मैं अपनी सेवा को कई प्रकार के फ्रंट-सिरों के लिए सुलभ कर दूंगा": आप जेएसओएन (या एक्सएमएल) के साथ आरईएसटी का उपयोग कर सकते हैं, जिसे गैर-जीडब्ल्यूटी ग्राहकों द्वारा भी समझा जा सकता है। ग्राहकों को स्विच करने के अलावा, यह आपको भविष्य में एक अलग सर्वर कार्यान्वयन (शायद गैर-जावा) पर स्विच करने की अनुमति देगा। नुकसान यह है कि आपको JSON ऑब्जेक्ट्स से अच्छी जावा ऑब्जेक्ट्स बनाने के लिए शायद GWT क्लाइंट पक्ष पर रैपर (JavaScript Overlay Types) या रूपांतरण कोड लिखना होगा। जब आप सेवा का एक नया संस्करण तैनात करते हैं, तो आपको विशेष रूप से सावधान रहना होगा, जो हमें प्रकार की सुरक्षा की कमी के लिए वापस लाता है।

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

Answer 2

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

Answer 3

मैं कहूंगा कि एक आरईएसटी बैकएंड बनाएं। मेरे पिछले प्रोजेक्ट में हमने पहले कुछ महीनों के लिए जीडब्ल्यूटी-आरपीसी का उपयोग करके विकास करना शुरू किया, हम तेजी से बूटस्ट्रैपिंग चाहते थे। बाद में, जब हमें आरईएसटी एपीआई की आवश्यकता थी, तो हम दो बैकएंड एपीआई (आरईएसटी और आरपीसी)

के साथ समाप्त होने वाले रिफैक्टरिंग के लिए इतना महंगा था, यदि आप उचित आरईएसटी बैकएंड बनाते हैं, और ग्राहक पक्ष पर एक deserialization infra (जेसन \ xml को जीडब्ल्यूटी जावा ऑब्जेक्ट्स में बदलने के लिए) तो आरपीसी का लाभ लगभग कुछ भी नहीं है।

आरईएसटी दृष्टिकोण का एक और कभी-कभी भूल गया लाभ यह है कि क्लाइंट चलाने वाले ब्राउज़र के लिए यह अधिक स्वाभाविक है, आरपीसी एक प्रोपेटेटरी प्रोटोकॉल है, जहां सभी अनुरोध पोस्ट का उपयोग कर रहे हैं। मानक तरीके से संसाधनों को पढ़ते समय आप क्लाइंट साइड कैशिंग से लाभ उठा सकते हैं।

उत्तर देना एम्स की टिप्पणियां: RPC प्रोटोकॉल के बारे में, पिछली बार मैं "सूंघा" यह फ़ायरबग का उपयोग कर इसे json की तरह नहीं था, इसलिए मुझे लगता है कि के बारे में पता नहीं है।हालांकि, यहां तक ​​कि यदि यह जेसन आधारित है, फिर भी यह सर्वर के साथ संवाद करने के लिए केवल HTTP POST विधि का उपयोग करता है, इसलिए कैशिंग के बारे में मेरा बिंदु अभी भी मान्य है, ब्राउज़र POST अनुरोधों को कैश नहीं करेगा।

पूर्वदर्शी के संबंध में और क्या बेहतर हो सकता है, संसाधन उन्मुख आर्किटेक्चर में आरपीसी सेवा लिखना बाद में आरईएसटी को आसान पोर्टिंग कर सकता है। याद रखें कि आरईएसटी में आमतौर पर बुनियादी सीआरयूडी संचालन के साथ संसाधनों का खुलासा होता है, यदि आप आरपीसी सेवा लिखते समय उस दृष्टिकोण पर ध्यान केंद्रित करते हैं तो आपको ठीक होना चाहिए।

Answer 4

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

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

यदि आपका आवेदन पूर्व गुणों की इच्छा रखता है, तो आरईएसटी शैली का उपयोग करें। यदि यह उत्तरार्द्ध चाहता है, तो आरपीसी शैली का उपयोग करें।

Answer 5

यदि आप RestyGWT प्रोजेक्ट का उपयोग भी करते हैं तो आप दोनों कर सकते हैं। यह आरडब्ल्यूटी आधारित जेएसओएन संसाधनों को जीडब्ल्यूटी-आरपीसी के उपयोग के रूप में आसान बना देगा। इसके अलावा आप आमतौर पर ग्राहक पक्ष पर सर्वर पक्ष से एक ही अनुरोध प्रतिक्रिया डीटीओ का पुन: उपयोग कर सकते हैं।

Answer 6

हमने उसी समस्या में भाग लिया जब हमने Spiffy UI Framework बनाया। हमने आरईएसटी चुना और मैं कभी वापस नहीं जाऊंगा। मैं यह भी कहूंगा कि जीडब्ल्यूटी-आरपीसी GWT Anti-pattern है।

आरईएसटी एक अच्छा विचार है भले ही आप कभी भी अपने आरईएसटी एंडपॉइंट्स का पर्दाफाश करना नहीं चाहते हैं। एक आरईएसटी एपीआई बनाने से आपका यूआई तेज हो जाएगा, आपका एपीआई बेहतर होगा, और आपका पूरा एप्लीकेशन अधिक रखरखाव योग्य होगा।

Answer 7

यदि आप सर्वर-साइड पर हाइबरनेट/जेपीए का उपयोग करके और परिणामी पीओजेओ को क्लाइंट (यानी फ़ोन के संग्रह के साथ एक कर्मचारी ऑब्जेक्ट) में संबंधपरक डेटा के साथ भेजने की योजना बना रहे हैं, तो निश्चित रूप से आरईएसटी कार्यान्वयन।

मैंने जीडब्ल्यूटी आरपीसी का उपयोग करके एक महीने पहले अपनी जीडब्ल्यूटी परियोजना शुरू की थी। जब तक मैंने अंतर्निहित डीबी से किसी ऑब्जेक्ट को एक-से-कई रिश्तों के साथ क्रमबद्ध करने की कोशिश नहीं की तब तक सब ठीक थे। और खतरनाक हो गया:

com.google.gwt.user.client.rpc.SerializationException: Type 'org.hibernate.collection.PersistentList' was not included in the set of types which can be serialized by this SerializationPolicy 

आप इस मुठभेड़ और GWT RPC के साथ रहना चाहते हैं आप की तरह कुछ का उपयोग करना होगा:

• GWT अनुरोध फैक्टरी (www.gwtproject.org/doc/latest /DevGuideRequestFactory.html) - जो आपको प्रति पीओजेओ में 3+ कक्षाएं/इंटरफेस लिखने के लिए मजबूर करता है, जिसे आप क्लाइंट के साथ साझा करना चाहते हैं। बहुत!
• गिलाद (sourceforge.net/projects/gilead/) - जो एक मृत परियोजना के लिए प्रतीत होता है।

अब मैं RestyGWT का उपयोग कर रहा हूं। स्विच काफी दर्द रहित था और मेरे POJO बिना किसी मुद्दे के क्रमबद्ध है।