ऐप इंजन - अनुरोध फैक्ट्री बनाम सर्वलेट्स अन्य एप्रोच बनाम

Question

हमारी टीम ऐप इंजन के साथ एंड्रॉइड एप्लिकेशन पर वापस काम कर रही है। क्लाइंट-सर्वर संचार के कार्यान्वयन के संबंध में हमारे विचारों पर कुछ अंतर है। पर एक हाथ App इंजन RequestFactory दृष्टिकोण है, जो (गूगल के रूप में कहते हैं)

provides a solid foundation for automatic batching and caching of requests in the future

और light-weighed

सुझाव दे लेकिन हम इस दृष्टिकोण एक छोटे से "अनाड़ी" पाते हैं। दूसरी ओर हम एक सामान्य सर्वलेट दृष्टिकोण का उपयोग कर सकते हैं जिसे हम अच्छी तरह से जानते हैं, और इसके साथ अधिक सहज महसूस करते हैं। हम निश्चित रूप से लाइटर, तेज और स्केलेबल संचार चाहते हैं, लेकिन किस अनुपात में अनुरोध फ़ैक्टरी वास्तव में उन्हें प्रदान करता है? हम दोनों दृष्टिकोणों से क्या हासिल और ढीला कर सकते हैं।

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

मुझे यहां कुछ समान प्रश्नों का उत्तर नहीं मिला। तो मुझे लगता है, यह कई लोगों के लिए एक उपयोगी चर्चा हो सकती है।

Answer 1

कुछ नोट:

1. RequestFactory AppEngine (here देखें) का एक हिस्सा नहीं है, लेकिन एक ऐड-ऑन नवीनतम Android ग्रहण प्लगइन द्वारा की शुरुआत की। मूल रूप से अनुरोध फैक्टरी जीडब्ल्यूटी के लिए बनाया गया था।

2. RequestFactory का उछाल यह है कि जीडब्ल्यूटी और एंड्रॉइड के साथ सहजता से काम करता है।

3. नकारात्मक पक्ष यह है .. यह नहीं पार मंच, iPhone के लिए अर्थात उपलब्ध नहीं, आदि है कि है

4. यह कैसे संस्करण RequestFactory को स्पष्ट नहीं है। यदि आपका ऐप बड़ा और विकसित हो रहा है, तो आपके पास ग्राहकों की सेवा करने वाले आरपीसी एपीआई के दो या दो से अधिक संस्करण होने चाहिए। जीडब्ल्यूटी ग्राहकों को आसानी से नवीनतम एपीआई (= पेज रीलोड) का उपयोग करने के लिए मजबूर किया जा सकता है, न कि एंड्रॉइड के साथ। AFAIK, दो RequestFactory endpoints होने का कोई विकल्प नहीं है। आरईएसटी के साथ आप अलग-अलग एपीआई संस्करणों के लिए बस कई यूआरएल प्राप्त कर सकते हैं।

5. सार्वजनिक/निजी एपीआई मिश्रण। चूंकि कोई भी एकाधिक अनुरोध फैक्ट्री एंडपॉइंट्स नहीं हैं, इसलिए आप उन्हें आसानी से सार्वजनिक रूप से विभाजित नहीं कर सकते हैं (कोई लेख आवश्यक नहीं है) और निजी/सुरक्षित (= auth आवश्यक)। आरईएसटी (और जीडब्ल्यूटी-आरपीसी) के साथ आप बस दो सर्लेट (निजी और सार्वजनिक) कर सकते हैं और web.xml में सुरक्षा बाधाएं सेट कर सकते हैं (या अपना स्वयं का सर्वलेट फ़िल्टर है)।

6. RequestFactory java.util.Map का समर्थन नहीं करता है। यह आपको गतिशील गुणों के साथ इकाइयों की क्षमता को गंभीर रूप से सीमित करता है - इसके लिए कामकाज हैं लेकिन वे आईएमओ एक अनावश्यक क्लज हैं (जैसे दो सूचियां, एक दूसरे के लिए मूल्यों के लिए कुंजी)।

समाधान:

1. एक सेवा परत है कि रिटर्न POJO डोमेन वस्तुओं बनाएँ: इस एक समाधान है कि मैं अपनी परियोजनाओं में इस्तेमाल करते हैं।

2. सेवा परत को कॉल करने वाली RPC परत बनाएं। आपके पास एक ही सेवा परत को कॉल करने वाली कई आरपीसी तकनीकें हो सकती हैं। मेरे पास आमतौर पर जीडब्ल्यूटी-आरपीसी और आरईएसटी है।

3. POJO-only डोमेन ऑब्जेक्ट्स का उपयोग करना कभी-कभी असंभव होता है (जेपीए/जेडीओ के कारण भी), इस प्रकार आप डीटीओ बनाने के लिए मजबूर होते हैं। डीटीओ बनाए रखने के लिए एक दर्द है और यदि संभव हो तो मैं उनसे बचने की कोशिश करता हूं। कुछ कामकाज के साथ अधिकांश समय डोमेन ऑब्जेक्ट्स का उपयोग करना संभव है: AppEngine पर आप निम्न स्तर/जेपीए/जेडीओ के बजाय ऑब्जेक्टिफ़ का उपयोग करके बहुत मदद प्राप्त कर सकते हैं। यह supports GWT-RPC है। आरईएसटी के साथ मैं सुझाव देता हूं कि आप जैक्सन का उपयोग करें जहां आप can do all kinds of custom conversions।