मैं जीडब्ल्यूटी-आरपीसी के आधार पर मेरी वर्तमान सेवा परत माइग्रेट करने पर सोच रहा हूं। यह लगभग 5 सेवा इंटरफेस है जिसमें प्रत्येक के 5 तरीके हैं, और इसमें लगभग 20 अलग-अलग डोमेन इकाइयां शामिल हैं, इसलिए आपको उस काम की मात्रा का एक अनुमान है जो पूरी चीज को बदलने की आवश्यकता होगी, जो स्पष्ट रूप से मैं कम करना चाहता हूं। मैं सभी आरपीसी अनुरोधों को संभालने के लिए गिलाद और एक गिइस आधारित केंद्रीकृत सर्वलेट का भी उपयोग कर रहा हूं।RestyGWT बनाम RequestFactory
बदलाव के लिए मुख्य कारण हैं:
- TypeSerializers एप्लिकेशन कोड के आकार का सबसे बड़ा हिस्सा उपभोग कर रहे हैं।
- ग्राहक पक्ष पर सीरियलाइजेशन/deserialization विशेष रूप से देव मोड पर धीमा है, जो जीडब्ल्यूटी-आरपीसी के साथ एक आम तथ्य प्रतीत होता है।
- जाहिर है, मैं ऑन-वायर पेलोड को कम करना चाहता हूं, लेकिन एक कठिन आवश्यकता नहीं है।
विकल्प है कि मैं के बारे में सोच रहा हूँ कर रहे हैं:
RequestFactory है, जो एक तेजी से जानवर के रूप में पदोन्नत किया गया है। लेकिन मुझे डर है कि क्लाइंट कोड ऑफ क्लाइंट कोड में उनके प्रॉक्सी समकक्षों के सभी संदर्भों को प्रतिस्थापित करने के लिए बहुत काम होगा, और मैं वास्तव में सभी प्रॉक्सी बनाने के लिए आलसी हूं।
RestyGWT का उपयोग कर एक पूर्ण JSON/REST दृष्टिकोण, जो ऐसा लगता है मुझे अभी भी डोमेन ऑब्जेक्ट्स का उपयोग करने देगा, लेकिन मुझे डर है कि यह धीमी गति से विलुप्त होने के साथ खत्म हो जाएगा? मैं किसी भी तथ्य पर आधारित नहीं हूं, लेकिन किसी भी तरह का बेंचमार्क नहीं मिला। यह सिर्फ एक छाप है।
मैं वास्तव में सुझाव प्राप्त करना चाहता हूं।
धन्यवाद!
इस बारे में सोचने की एक और बात यह है कि पूर्ण JSON/REST दृष्टिकोण अन्य क्लाइंट को आपके सर्वर से अधिक आसानी से बातचीत करने की अनुमति देता है। –
यह सच है, और JSON/REST के पक्ष में एक बिंदु है। लेकिन मुझे अब प्रदर्शन के बारे में और अधिक परवाह है। इसके अलावा मैं जीडब्ल्यूटी के साथ मोबाइल क्लाइंट विकसित करने की भी योजना बना रहा हूं, जब तक कि मैं भविष्य में बहुत दूर नहीं जाता, मैं सेवा सेवा के साथ ठीक हूं जो केवल जीडब्ल्यूटी के साथ काम करता है। –
क्या आपने जीडब्ल्यूटी ओवरले प्रकारों का उपयोग करने पर विचार किया है? वे बहुत कम deserialization लागत (लगभग परिभाषा के अनुसार) के साथ आते हैं। – Hbf