मुझे GWT-RPC बनाम RequestFactory का उपयोग कब करना चाहिए?

Question 1

मैं यह पता लगाने की कोशिश कर रहा हूं कि मुझे अपने gwt-rpc कॉल को नए GWT2.1 RequestFactory cals में स्थानांतरित करना चाहिए या नहीं।

Google प्रलेखन ने उल्लेख किया है कि "डेटा-उन्मुख सेवाओं" के लिए RequestFactory एक बेहतर क्लाइंट-सर्वर संचार विधि है

मैं प्रलेखन से क्या विचलित कर सकता है कि एक नया प्रॉक्सी वर्ग है जो संचार को सरल बनाता है (आप वास्तविक इकाई से आगे और पीछे नहीं जाते हैं, लेकिन सिर्फ प्रॉक्सी है, इसलिए यह हल्का वजन और प्रबंधन करने में आसान है)

क्या यह पूरी बात है या मुझे बड़ी तस्वीर में कुछ और याद आ रहा है?

Question 2

GWT RPC और RequestFactory के बीच बड़ा अंतर यह है कि RPC सिस्टम "RPC-by-ठोस-प्रकार" है, जबकि RequestFactory "RPC-by-interface" है।

आरपीसी शुरू करने के लिए अधिक सुविधाजनक है, क्योंकि आप कोड की कम पंक्तियाँ लिखते हैं और क्लाइंट और सर्वर दोनों पर समान वर्ग का उपयोग करते हैं। आप Personगेटर्स और बस्तियों के एक समूह के साथ एक वर्ग बना सकते हैं और शायद Personऑब्जेक्ट में डेटा के और अधिक टुकड़ा करने की क्रिया के लिए कुछ सरल व्यापार तर्क । यह तब तक बहुत अच्छा काम करता है जब तक कि आप अपनी कक्षा के अंदर सर्वर-विशिष्ट, गैर-जीडब्ल्यूटी-संगत, कोड को प्राप्त करना चाहते हैं। चूँकि RPC सिस्टम क्लाइंट और सर्वर दोनों पर एक ही ठोस प्रकार होने पर आधारित है, इसलिए आप अपने GWT क्लाइंट की क्षमताओं के आधार पर एक जटिलता की दीवार से टकरा सकते हैं।

असंगत कोड के उपयोग के आसपास पाने के लिए, कई उपयोगकर्ता एक सहकर्मी का निर्माण करते हैं जो सर्वर पर प्रयुक्त PersonDTOवास्तविक Personवस्तु को छाया देता है। PersonDTOबस getters और setters सर्वर साइड की, "डोमेन", का उप-समूह Personवस्तु। अब आप कोड लिखने के लिए है के बीच marshalls डेटा PersonऔरPersonDTO वस्तु और अन्य सभी वस्तु प्रकार है कि आप ग्राहक को भेजना चाहते हैं।

आपके डोमेन ऑब्जेक्ट GWT- संगत नहीं होने जा रहे हैं यह मानकर RequestFactory शुरू होता है। आप बस प्रॉक्सी कोड में क्लाइंट कोड द्वारा पढ़ी और लिखी जाने वाली संपत्तियों की घोषणा करते हैं, और RequestFactory सर्वर घटक डेटा को मार्श करने और आपकी सेवा विधियों को लागू करने का ध्यान रखते हैं। "एंटिटीज़" या "पहचान और संस्करण के साथ ऑब्जेक्ट्स" की एक अच्छी तरह से परिभाषित अवधारणा वाले अनुप्रयोगों के लिए, EntityProxyप्रकार का उपयोग क्लाइंट कोड में आपके डेटा की लगातार पहचान शब्दार्थ को उजागर करने के लिए किया जाता है। सरल वस्तुओं को ValueProxyप्रकार का उपयोग करके मैप किया जाता है ।

RequestFactory के साथ, आप GWT RPC की तुलना में अधिक जटिल प्रणालियों को आसानी से समर्थन करने के लिए एक अप-फ्रंट स्टार्टअप लागत का भुगतान करते हैं। RequestFactory, उदाहरणों ServiceLayerको जोड़कर अपने व्यवहार को अनुकूलित करने के लिए काफी अधिक हुक प्रदान करता है ServiceLayerDecorator।

Question 3

मैं आरपीसी से आरएफ में एक संक्रमण से गुजरा। पहले मुझे यह कहना है कि मेरा अनुभव उसी में सीमित है, मैंने 0 के रूप में कई EntityProxies का उपयोग किया।

GWT RPC के लाभ:

यह स्थापित करना, समझना और सीखना आसान है!
क्लाइंट और सर्वर पर समान श्रेणी-आधारित ऑब्जेक्ट का उपयोग किया जाता है।
यह दृष्टिकोण टन के कोड को बचाता है।
आदर्श, जब एक ही मॉडल ऑब्जेक्ट (और POJOS) का उपयोग क्लाइंट और सर्वर पर किया जाता है, तो POJOs == मॉडल OBJECTs == DTO
सर्वर से क्लाइंट तक सामान ले जाना आसान।
क्लाइंट और सर्वर के बीच आम तर्क के कार्यान्वयन को साझा करना आसान है (जब आपको अलग तर्क की आवश्यकता होती है तो यह महत्वपूर्ण नुकसान के रूप में सामने आ सकता है)।

GWT RPC की अस्वीकृति:

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

अनुरोध के नुकसान:

वास्तव में आधिकारिक डॉक्टर से समझने के लिए, इसका गुण क्या है! यह पूरी तरह से भ्रामक शब्द PROXIES पर सही शुरू होता है - ये वास्तव में आरएफ के डीटीओ हैं जो आरएफ द्वारा स्वचालित रूप से बनाए जाते हैं। प्रॉक्सी को इंटरफेस द्वारा परिभाषित किया गया है, जैसे @ProxyFor (Journal.class)। आईडीई जाँच करता है कि क्या जर्नल पर संबंधित विधियाँ मौजूद हैं। मैपिंग के लिए बहुत कुछ।
क्योंकि क्लाइंट और सर्वर की समानता के संदर्भ में RF आपके लिए बहुत कुछ नहीं करेगा
क्लाइंट पर आपको "PROXIES" को अपने क्लाइंट डोमेन ऑब्जेक्ट में बदलने की जरूरत है और इसके विपरीत। यह पूरी तरह से हास्यास्पद है। यह घोषित रूप से कोड की कुछ पंक्तियों में किया जा सकता है, लेकिन इसके लिए कोई समर्थन नहीं है! यदि केवल हम अपने डोमेन ऑब्जेक्ट को अधिक सुरुचिपूर्ण ढंग से समतल करने के लिए मैप कर सकते हैं, तो जावास्क्रिप्ट विधि JSON.stringify (.. ,,) जैसे कुछ आरएफ टूलबॉक्स में MISSING है।
यह मत भूलो कि आप अपने डोमेन ऑब्जेक्ट्स के हस्तांतरणीय गुणों को परदे के पीछे स्थापित करने के लिए जिम्मेदार हैं, और इसी तरह पुनरावर्ती भी।
सर्वर पर प्रमुख त्रुटि और - स्टैक-निशान सर्वर पर डिफ़ॉल्ट रूप से छोड़े गए हैं और आप क्लाइंट पर खाली बेकार अपवाद प्राप्त कर रहे हैं। जब मैं कस्टम त्रुटि हैंडलर सेट करता था, तब भी मैं निम्न-स्तरीय स्टैक के निशान को प्राप्त करने में सक्षम नहीं था! भयानक।
आईडीई समर्थन और अन्य जगहों पर कुछ मामूली कीड़े। मैंने दो बग निवेदन दायर किए जो स्वीकार किए गए। नहीं आइंस्टीन को यह पता लगाने की जरूरत थी कि वे वास्तव में कीड़े थे।
डॉक्यूमेंटेशन SUCKS। जैसा कि मैंने उल्लेख किया है कि प्रॉक्सी को बेहतर ढंग से समझाया जाना चाहिए, यह शब्द MISLEADING है। बुनियादी सामान्य समस्याओं के लिए, जो मैं हल कर रहा था, डॉक्स यूएस यूएसईएलएस। DOC से गलतफहमी का एक और उदाहरण आरएफ को JPA एनोटेशन का कनेक्शन है। यह रसीला डॉक्स से लगता है कि वे थोड़े साथ खेलते हैं, और हां, स्टैकऑवरफ्लो पर एक संबंधित प्रश्न है। मैं आरएफ को समझने से पहले किसी भी जेपीए 'कनेक्शन' को भूलने की सलाह देता हूं।

RequestFactory के लाभ

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

सामान्य रूप से GWT के अन्य नुकसानों को ध्यान में रखते हुए:

प्रदान किए गए एकीकरण परीक्षणों (GWT क्लाइंट कोड + रिमोट सर्वर) को चलाने के लिए असंभव JUnit समर्थन के साथ <= सभी JSNI को मज़ाक करना पड़ता है (जैसे स्थानीयस्टोरेज), SOP एक मुद्दा है।
परीक्षण सेटअप के लिए कोई समर्थन नहीं - हेडलेस ब्राउज़र + रिमोट सर्वर <= GWT, SOP के लिए कोई सरल हेडलेस परीक्षण नहीं।
हां, सेलेनियम एकीकरण परीक्षण चलाना संभव है (लेकिन यह वह नहीं है जो मैं चाहता हूं)
JSNI बहुत शक्तिशाली है, लेकिन उन चमकदार वार्ता में वे सम्मेलनों में देते हैं, वे इस बारे में ज्यादा बात नहीं करते हैं कि JSNI कोड लिखने के कुछ नियम भी हैं। फिर, यह पता लगाना कि एक साधारण कॉलबैक कैसे लिखा जाता है, एक सच्चे शोधकर्ता के लायक काम था।

सारांश में, GWT RPC से RequestFactory में परिवर्तन, WIN-WIN स्थिति से बहुत दूर है, जब RPC ज्यादातर आपकी आवश्यकताओं के अनुरूप होती है। आप क्लाइंट डोमेन ऑब्जेक्ट से प्रॉक्सी और इसके विपरीत में टन रूपांतरण लिख रहे हैं। लेकिन आपको अपने समाधान की थोड़ी लचीलापन और मजबूती मिलती है। और मंच पर समर्थन उत्कृष्ट है, शनिवार को भी!

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

Question 4

मुझे अपनी सभी संस्थाओं के लिए प्रॉक्सी कक्षाएं बनाने का विचार काफी कष्टप्रद लगता है। मेरे हाइबरनेट / जेपीए पॉजोस डेटाबेस मॉडल से ऑटो-जेनरेट किए जाते हैं। अब मुझे RPC के लिए दूसरा दर्पण बनाने की आवश्यकता क्यों है? हमारे पास एक अच्छा "एस्टीटेशन" ढांचा है जो कि "डी-हाइबरनेटिंग" पॉजोस का ख्याल रखता है।

इसके अलावा, सेवा इंटरफेस को परिभाषित करने का विचार जो एक जावा अनुबंध के रूप में सर्वर साइड सेवा को लागू नहीं करता है, लेकिन तरीकों को लागू करता है - मुझे बहुत J2EE 1.x / 2.x लगता है।

Question 5

RequestFactory के विपरीत जिसमें खराब त्रुटि से निपटने और परीक्षण क्षमताएं हैं (चूंकि यह GWT के हुड के तहत अधिकांश सामान की प्रक्रिया करता है), RPC आपको अधिक सेवा उन्मुख दृष्टिकोण का उपयोग करने की अनुमति देता है। RequestFactory एक और अधिक आधुनिक निर्भरता इंजेक्शन स्टाइल दृष्टिकोण को लागू करता है जो कि एक उपयोगी दृष्टिकोण प्रदान कर सकता है यदि आपको जटिल पॉलीमॉर्फिक डेटा संरचनाओं को लागू करने की आवश्यकता है। आरपीसी का उपयोग करते समय आपकी डेटा संरचनाओं को अधिक सपाट होना होगा, क्योंकि इससे आपके मार्शलों को आपके जसन / xml और जावा मॉडल के बीच अनुवाद करने की सुविधा मिलेगी। RPC का उपयोग करने से आप Google की वेबसाइट पर gwt dev सेक्शन के हवाले से अधिक मजबूत आर्किटेक्चर को लागू कर सकते हैं।

"सरल क्लाइंट / सर्वर परिनियोजन

सेवा परिभाषाओं के बारे में सोचने का पहला और सबसे सरल तरीका यह है कि आप उन्हें अपने एप्लिकेशन के संपूर्ण बैक एंड के रूप में मानें। इस दृष्टिकोण से, क्लाइंट-साइड कोड आपका "फ्रंट एंड" है और सर्वर पर चलने वाला सभी सर्विस कोड "बैक एंड" है। यदि आप इस दृष्टिकोण को लेते हैं, तो आपकी सेवा कार्यान्वयन अधिक सामान्य-उद्देश्य वाले एपीआई होंगे जो एक विशिष्ट अनुप्रयोग के साथ युग्मित नहीं हैं। आपकी सेवा परिभाषाओं में संभवतः JDBC या हाइबरनेट या सर्वर फाइल सिस्टम में मौजूद फ़ाइलों के माध्यम से सीधे डेटाबेस तक पहुँचने की संभावना होगी। कई अनुप्रयोगों के लिए, यह दृश्य उपयुक्त है, और यह बहुत कुशल हो सकता है क्योंकि यह स्तरों की संख्या को कम करता है।

मल्टी-टीयर तैनाती

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

यह भी ध्यान दें कि एकल अनुरोध सेवा की स्थापना के लिए लगभग 6 या जावा वर्ग बनाने की आवश्यकता होती है, जहाँ RPC के लिए केवल 3. आवश्यकता होती है 3. अधिक कोड == मेरी पुस्तक में अधिक त्रुटियाँ और जटिलता।

रिक्वेस्ट प्रोसेसिंग के दौरान रिक्वेस्ट फैक्ट्री में भी थोड़ा अधिक ओवरहेड होता है, क्योंकि इसमें डेटा प्रॉक्सि और वास्तविक जावा मॉडल्स के बीच मार्शलाइजेशन होता है। यह जोड़ा इंटरफ़ेस अतिरिक्त प्रसंस्करण चक्र जोड़ता है जो वास्तव में एक उद्यम या उत्पादन वातावरण में जोड़ सकता है।

मैं यह भी नहीं मानता कि RequestFactory सेवाएँ RPC सेवाओं की तरह क्रमबद्धता हैं।

सभी कुछ समय के लिए दोनों का उपयोग करने के बाद, मैं हमेशा अपने अधिक हल्के, परीक्षण और डिबग के रूप में आरपीसी के साथ जाता हूं, और फिर एक RequestFactory का उपयोग करके। हालाँकि RequestFactory अधिक सुरुचिपूर्ण और एक्स्टेंसिबल हो सकता है फिर इसका RPC काउंटर भाग। जोड़ा जटिलता यह एक बेहतर उपकरण आवश्यक नहीं है।

मेरी राय है कि सबसे अच्छा आर्किटेक्चर दो वेब ऐप, एक क्लाइंट और एक सर्वर का उपयोग करना है। सर्वर एक साधारण हल्का जेनेरिक जावा वेबप है जो सर्वलेट.जर लाइब्रेरी का उपयोग करता है। ग्राहक GWT है। आप क्लाइंट वेब एप्लिकेशन के सर्वर साइड में GWT-RPC के माध्यम से RESTful अनुरोध करते हैं। क्लाइंट का सर्वर साइड सिर्फ एक पास है, हालांकि http क्लाइंट को अपाचे करने के लिए जो आपके सर्वर सर्वलेट वेब एप्लिकेशन में सिंगल सर्वलेट के रूप में चल रहा है। सर्वलेट वेब एप्लिकेशन में आपके डेटाबेस एप्लिकेशन की परत (हाइबरनेट, सेयेन, एसक्यूएल आदि शामिल होनी चाहिए।) यह आपको वास्तविक क्लाइंट से डेटाबेस ऑब्जेक्ट मॉडल को पूरी तरह से तलाक देने की अनुमति देता है जो आपके एप्लिकेशन को विकसित करने और इकाई परीक्षण करने के लिए बहुत अधिक व्यापक और मजबूत तरीका प्रदान करता है। दी कि इसके लिए प्रारंभिक सेटअप समय की एक बिट की आवश्यकता होती है, लेकिन अंत में आपको GWT के बाहर बैठकर एक गतिशील अनुरोध कारखाना बनाने की अनुमति मिलती है। यह आपको दोनों दुनिया के सर्वश्रेष्ठ का लाभ उठाने की अनुमति देता है। Gwt क्लाइंट को संकलित या बनाने के लिए बिना अपने सर्वर साइड में परीक्षण करने और परिवर्तन करने में सक्षम होने का उल्लेख नहीं है।

Question 6

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

Question 7

केवल एक ही चेतावनी जो मैं सामने रखूंगा वह है कि RequestFactory बाइनरी डेटा ट्रांसपोर्ट (deRPC हो सकता है?) का उपयोग करता है और सामान्य GWT-RPC का नहीं।

यह केवल तभी मायने रखता है जब आप SyncProxy, Jmeter, Fiddler, या किसी भी समान टूल के साथ भारी परीक्षण कर रहे हों, जो HTTP अनुरोध / प्रतिक्रिया (जैसे GWT-RPC) की सामग्री को पढ़ / मूल्यांकन कर सकता है, लेकिन deRPC या RequestFactory के लिए अधिक चुनौतीपूर्ण होगा।

Question 8

हमारे पास हमारी परियोजना में GWT-RPC का बहुत बड़ा कार्यान्वयन है। वास्तव में हम प्रत्येक के कई तरीकों के साथ 50 सेवा इंटरफेस है, और हम संकलक द्वारा उत्पन्न TypeSerializers के आकार के साथ समस्या है जो हमारे JS कोड को विशाल बनाता है। इसलिए हम RequestFactory की ओर बढ़ने की घोषणा कर रहे हैं। मुझे वेब पर खुदाई करने और कुछ अन्य लोगों को खोजने की कोशिश करने के लिए कुछ दिनों के लिए पढ़ा गया है। सबसे महत्वपूर्ण कमी जो मैंने देखी, और शायद मैं गलत हो सकता है, यह है कि RequestFactory के साथ आपके सर्वर डोमेन ऑब्जेक्ट्स और आपके क्लाइंट के बीच संचार का नियंत्रण नहीं रह जाता है। हमें लोड / सेव पैटर्न को नियंत्रित तरीके से लागू करने की आवश्यकता है। मेरा मतलब है, उदाहरण के लिए ग्राहक एक विशिष्ट लेनदेन से संबंधित वस्तुओं के पूरे ऑब्जेक्ट ग्राफ को प्राप्त करते हैं, अपने अपडेट करते हैं और वे पूरे सर्वर पर वापस भेजते हैं। सर्वर सत्यापन करने के लिए ज़िम्मेदार होगा, पुराने की तुलना नए मूल्यों के साथ करेगा और दृढ़ता करेगा। यदि अलग-अलग साइटों के 2 उपयोगकर्ता एक ही लेन-देन करते हैं और कुछ अपडेट करते हैं, तो परिणामस्वरूप लेनदेन को मर्ज नहीं किया जाना चाहिए। अपडेट में से एक को मेरे परिदृश्य में विफल होना चाहिए। मैं यह नहीं देखता कि RequestFactory इस तरह के प्रसंस्करण का समर्थन करने में मदद करता है।

सादर डैनियल

Question 9

क्या यह कहना उचित है कि जब एक सीमित एमआईएस एप्लिकेशन पर विचार किया जाता है, तो 10-20 CRUD'able व्यावसायिक वस्तुओं के साथ कहें, और प्रत्येक के साथ ~ 1-10 गुण, कि वास्तव में यह व्यक्तिगत प्राथमिकता के लिए नीचे है जो किस मार्ग से जाना है?

यदि ऐसा है, तो शायद यह अनुमान लगाना कि आपका आवेदन किस तरह से हो रहा है, आपके मार्ग को चुनने में महत्वपूर्ण हो सकता है

मेरे आवेदन से अपेक्षा की जाती है कि वे अपेक्षाकृत सीमित संख्या में संस्थाओं के साथ रहें लेकिन उनकी संख्या के मामले में बड़े पैमाने पर वृद्धि होगी। 10-20 ऑब्जेक्ट्स * 100,000 रिकॉर्ड।
मेरा आवेदन संस्थाओं की चौड़ाई में काफी वृद्धि करने वाला है, लेकिन प्रत्येक में शामिल रिश्तेदार संख्या कम रहेगी। 5000 ऑब्जेक्ट्स * 100 रिकॉर्ड।
मेरे आवेदन से अपेक्षा है कि वह अपेक्षाकृत सीमित संख्या में संस्थाओं के साथ रहेगा और अपेक्षाकृत कम संख्या में जैसे 10-20 ऑब्जेक्ट * 100 रिकॉर्ड में रहेगा

मेरे मामले में, मैं यह निर्णय लेने की कोशिश कर रहा हूं। UI क्लाइंट साइड आर्किटेक्चर को बदलने के साथ-साथ परिवहन विकल्प बनाने से भी जटिल है। मेरे पिछले (महत्वपूर्ण रूप से) बड़े पैमाने पर GWT UI ने Hmvc4Gwt लाइब्रेरी का उपयोग किया, जिसे GWT MVP सुविधाओं से अलग किया गया है।