RequestFactory ve GWT-RPC'yi ne zaman kullanmalıyım?


87

Gwt-rpc çağrılarımı yeni GWT2.1 RequestFactory cals'ına geçirmem gerekip gerekmediğini anlamaya çalışıyorum.

Google dokümantasyonu, RequestFactory'nin "veri odaklı hizmetler" için daha iyi bir istemci-sunucu iletişim yöntemi olduğundan belirsiz bir şekilde bahsediyor

Dokümantasyondan ayrıştırabileceğim şey, iletişimi basitleştiren yeni bir Proxy sınıfının olmasıdır (gerçek varlığı değil, yalnızca proxy'yi iletirsiniz, bu nedenle daha hafiftir ve yönetimi daha kolaydır)

Bütün mesele bu mu yoksa büyük resimde başka bir şeyi mi özlüyorum?


Yanıtlar:


73

GWT RPC ve RequestFactory arasındaki en büyük fark, RPC sisteminin "betona göre RPC", RequestFactory'nin ise "arabirime göre RPC" olmasıdır.

RPC'yi kullanmaya başlamak daha uygundur, çünkü daha az kod satırı yazarsınız ve hem istemcide hem de sunucuda aynı sınıfı kullanırsınız. Nesnedeki Personverileri daha fazla dilimlemek ve parçalara ayırmak için bir grup alıcı ve ayarlayıcı ile bir sınıf ve belki bazı basit iş mantığı oluşturabilirsiniz Person. Bu, sınıfınızda sunucuya özgü, GWT uyumlu olmayan bir koda sahip olmak isteyene kadar oldukça iyi çalışır. RPC sistemi hem istemcide hem de sunucuda aynı somut türe sahip olmaya dayandığından, GWT istemcinizin yeteneklerine bağlı olarak karmaşık bir duvara çarpabilirsiniz.

Uyumsuz kod kullanımının üstesinden gelmek için birçok kullanıcı , sunucuda kullanılan PersonDTOgerçek Personnesneyi gölgeleyen bir eş oluşturur . PersonDTOSadece sunucu tarafı alıcılar ve belirleyiciler, "etki", bir alt kümesi vardır Personnesne. Şimdi, Personve PersonDTOnesnesi ile istemciye iletmek istediğiniz diğer tüm nesne türleri arasındaki verileri sıralayan kod yazmanız gerekir .

RequestFactory, etki alanı nesnelerinizin GWT uyumlu olmayacağını varsayarak başlar. Bir Proxy arabiriminde istemci kodu tarafından okunması ve yazılması gereken özellikleri bildirirsiniz ve RequestFactory sunucu bileşenleri verileri sıralamak ve hizmet yöntemlerinizi çağırmakla ilgilenir. İyi tanımlanmış bir "Varlıklar" veya "Kimlik ve sürüme sahip nesneler" kavramına sahip uygulamalar için EntityProxytür, verilerinizin kalıcı kimlik anlamını istemci koduna maruz bırakmak için kullanılır. Basit nesneler, ValueProxytür kullanılarak eşlenir .

RequestFactory ile, GWT RPC'nin kolayca desteklediğinden daha karmaşık sistemleri barındırmak için önceden bir başlangıç ​​maliyeti ödersiniz. RequestFactory'ler ServiceLayer, ServiceLayerDecoratorörnekler ekleyerek davranışını özelleştirmek için önemli ölçüde daha fazla kanca sağlar .


Bu, RequestFactory'ye geçme kararımı desteklemek için iyi bir nedendir. Teşekkür ederim Bob! Bu mantıklı ve neden bazılarının "ihtiyaçlarınıza bağlı olarak bazı durumlarda RPC ve diğerlerinde RF kullanın" dediğini anlamıyorum çünkü RPC ile çok fazla yapıştırıcı kod yazmanız gerekiyor ve o DTO katmanı
Dan L.

5
RequestFactory'nin bir diğer artısı da aynı kodla Android ve GWT ile kullanılabiliyor olması.
Patrick

28

RPC'den RF'ye geçiş yaptım. Öncelikle deneyimlerimin sınırlı olduğunu söylemeliyim, 0 kadar EntityProxies kullandım.

GWT RPC'nin Avantajları:

  • Kurmak, anlamak ve ÖĞRENMEK çok kolay!
  • İstemcide ve sunucuda aynı sınıf tabanlı nesneler kullanılır.
  • Bu yaklaşım tonlarca kod tasarrufu sağlar.
  • İdeal, aynı model nesneler (ve POJOS) hem istemci hem de sunucuda kullanıldığında, POJOs == MODEL OBJECTs == DTOs
  • Öğeleri sunucudan istemciye taşımak kolaydır.
  • İstemci ve sunucu arasında ortak mantık uygulamasının paylaşılması kolaydır (bu, farklı bir mantığa ihtiyaç duyduğunuzda kritik bir dezavantaj olarak ortaya çıkabilir).

GWT RPC'nin Dezavantajları:

  • Sunucu ve istemci için bazı yöntemlerin farklı uygulamalarına sahip olmak imkansızdır, örneğin, istemci ve sunucu üzerinde farklı kayıt çerçevesi veya farklı eşitlik yöntemi kullanmanız gerekebilir.
  • Daha fazla genişletilemeyen GERÇEKTEN KÖTÜ uygulama: sunucu işlevlerinin çoğu bir RPC sınıfında statik yöntemler olarak uygulanır. Gerçekten berbat.
  • Örneğin, sunucu tarafı hataları gizleme eklemek imkansız
  • Kolayca çözülemeyen bazı güvenlik XSS endişeleri, belgelere bakın (Bunun RequestFactory için daha şık olup olmadığından emin değilim)

RequestFactory'nin dezavantajları:

  • Resmi belgeden anlamak GERÇEKTEN ZOR, bunun değeri nedir! Tamamen yanıltıcı bir terim olan PROXIES ile başlar - bunlar aslında RF tarafından otomatik olarak oluşturulan RF DTO'larıdır. Proxy'ler arabirimler tarafından tanımlanır, örneğin @ProxyFor (Journal.class). IDE, Journal'da karşılık gelen yöntemler olup olmadığını kontrol eder. Haritalama için çok fazla.
  • RF, istemci ve sunucu ortaklıkları açısından sizin için pek bir şey yapmayacaktır çünkü
  • İstemcide "PROXIES" i istemci etki alanı nesnelerinize ve tersi yönde dönüştürmeniz gerekir. Bu tamamen saçma. Açıklamalı olarak birkaç satır kodla yapılabilir, ancak BUNU DESTEKLEMEZ! Keşke etki alanı nesnelerimizi proxy'lere daha zarif bir şekilde eşleyebilseydik, JavaScript yöntemi JSON.stringify (.. ,,) gibi bir şey RF araç kutusunda Kayıp oluyor.
  • Etki alanı nesnelerinizin aktarılabilir özelliklerini proxy'lere vb. Yinelemeli olarak ayarlamaktan da sorumlu olduğunuzu unutmayın.
  • Sunucuda KÖTÜ HATA İŞLEME ve - Sunucuda varsayılan olarak yığın izleri atlanır ve istemcide boş gereksiz istisnalar alıyorsunuz. Özel hata işleyiciyi belirlediğimde bile, düşük seviyeli yığın izlerine ulaşamadım! Korkunç.
  • IDE desteğinde ve başka yerlerde bazı küçük hatalar. Kabul edilen iki hata talebinde bulundum. Bunların aslında böcek olduğunu anlamak için bir Einstein'a gerek yoktu.
  • DOKÜMANTASYON EMİŞLER. Vekillerin daha iyi açıklanması gerektiğini söylediğim gibi, bu terim YANLIŞ YOLCU. Çözmekte olduğum temel yaygın sorunlar için DOCS KULLANILAMAZ. DOC'tan gelen bir başka yanlış anlama örneği, JPA ek açıklamalarının RF'ye bağlanmasıdır. Kısa ve öz belgelerden birlikte oynadıkları anlaşılıyor ve evet, StackOverflow'da buna karşılık gelen bir soru var. RF'yi anlamadan önce herhangi bir JPA 'bağlantısını' unutmanızı tavsiye ederim.

RequestFactory'nin Avantajları

  • Mükemmel forum desteği.
  • IDE desteği oldukça iyidir (ancak RPC'nin aksine bir avantaj değildir)
  • İstemci ve sunucu uygulamanızın esnekliği (gevşek bağlantı)
  • Basit DTO'ların ötesinde EntityProxies'e bağlı fantezi şeyler - önbelleğe alma, kısmi güncellemeler, mobil için çok kullanışlı.
  • ValueProxies'i DTO'ların en basit ikamesi olarak kullanabilirsiniz (ancak tüm dönüşümleri o kadar da süslü yapmak zorunda değilsiniz).
  • Bean Validations JSR-303 desteği.

Genel olarak GWT'nin diğer dezavantajlarını göz önünde bulundurarak:

  • Sağlanan JUnit desteği ile entegrasyon testleri (GWT istemci kodu + uzak sunucu) çalıştırmak imkansız <= tüm JSNI'ların alay edilmesi gerekir (örn. LocalStorage), SOP bir sorundur.

  • Test kurulumu için destek yok - başsız tarayıcı + uzak sunucu <= GWT, SOP için basit başsız test yok.

  • Evet, selenyum entegrasyon testleri çalıştırmak mümkün (ama istediğim bu değil)

  • JSNI çok güçlüdür, ancak konferanslarda yaptıkları parlak konuşmalarda JSNI kodlarının yazılmasının da bazı kuralları olduğu hakkında pek konuşmazlar. Yine, basit bir geri aramanın nasıl yazılacağını bulmak gerçek bir araştırmacının göreviydi.

Özetle, GWT RPC'den RequestFactory'ye geçiş, RPC'nin çoğunlukla ihtiyaçlarınıza uygun olduğu WIN-WIN durumundan uzaktır. İstemci etki alanı nesnelerinden proxy'lere ve tersi yönde tonlarca dönüşüm yazarsınız. Ancak çözümünüzde biraz esneklik ve sağlamlık elde edersiniz. Forumdaki destek Cumartesi günü de mükemmel!

Az önce bahsettiğim tüm avantajları ve dezavantajları göz önüne aldığımızda, bu yaklaşımlardan herhangi birinin çözümünüze ve geliştirme yapınıza büyük ödünler vermeden gerçekten iyileştirme getirip getirmediğini önceden düşünmek gerçekten çok faydalı.


Checkout JBoss Erai. RPC'ye yaklaşımlarını seviyorum.
Καrτhικ

6

Tüm varlıklarım için Proxy sınıfları oluşturma fikrini oldukça sinir bozucu buluyorum. Hibernate / JPA pojo'larım veritabanı modelinden otomatik olarak oluşturuldu. Neden şimdi RPC için bunlardan ikinci bir ayna oluşturmam gerekiyor? Pojo'ları "kış uykusuna sokmak" ile ilgilenen güzel bir "estivation" çerçevemiz var.

Ayrıca, sunucu tarafı hizmetini bir java sözleşmesi olarak tam olarak uygulamayan ancak yöntemleri uygulayan hizmet arabirimlerini tanımlama fikri bana çok J2EE 1.x / 2.x geliyor.


5
Can sıkıcı bir durum, ancak yine de proxy'ler oluşturmanız gerekiyorsa, bu proxy'leri yönetmek için RF'nin size verdiği ekstra yardımı tercih edersiniz. Herkes pojo'nun tamamını müşteriye göndermek istemez - örneğin, bir poker oyunu düşünün - Oyuncu nesneniz, herkesin görmesi gereken bilgilere (eldeki kart sayısı, açık kartlar, toplam fişler) ve yalnızca bir oyuncu görmelidir (kapalı kartlar).
Peter Recore

Poker örneğiniz geçerlidir - "estivation" çerçevemizin değerleri bastırmak için kullandığı ek açıklamalara (@WireTransient) sahip olarak bu konuda çalışıyoruz.
Καrτhικ

4

Zayıf hata işleme ve test etme yeteneklerine sahip olan RequestFactory'nin aksine (çoğu şeyi GWT kapsamında işlediğinden), RPC daha hizmet odaklı bir yaklaşım kullanmanıza izin verir. RequestFactory, karmaşık polimorfik veri yapılarını çağırmanız gerektiğinde kullanışlı bir yaklaşım sağlayabilen daha modern bir bağımlılık enjeksiyon stili yaklaşımı uygular. RPC'yi kullanırken, veri yapılarınızın daha düz olması gerekecektir, çünkü bu, sıralama araçlarınızın json / xml ve java modelleriniz arasında çeviri yapmasına izin verecektir. RPC'yi kullanmak, Google'ın web sitesindeki gwt dev bölümünden alıntılandığı gibi daha sağlam mimari uygulamanıza da olanak tanır.

"Basit İstemci / Sunucu Dağıtımı

Hizmet tanımlarını düşünmenin ilk ve en basit yolu, bunları uygulamanızın tüm arka ucu olarak ele almaktır. Bu perspektiften, istemci tarafı kodu sizin "ön uç "unuzdur ve sunucuda çalışan tüm hizmet kodu" arka uç "dur. Bu yaklaşımı kullanırsanız, hizmet uygulamalarınız belirli bir uygulamaya sıkı sıkıya bağlı olmayan daha genel amaçlı API'ler olma eğiliminde olacaktır. Hizmet tanımlarınız büyük olasılıkla JDBC veya Hazırda Bekletme aracılığıyla veritabanlarına veya hatta sunucunun dosya sistemindeki dosyalara doğrudan erişecektir. Birçok uygulama için bu görünüm uygundur ve katman sayısını azalttığı için çok verimli olabilir.

Çok Katmanlı Dağıtım

Daha karmaşık, çok katmanlı mimarilerde, GWT hizmet tanımlarınız, J2EE sunucuları gibi arka uç sunucu ortamlarına çağrı yapan basit ağ geçitleri olabilir. Bu açıdan, hizmetleriniz, uygulamanızın kullanıcı arayüzünün "sunucu yarısı" olarak görülebilir. Hizmetler, genel amaçlı olmak yerine, kullanıcı arayüzünüzün özel ihtiyaçları için oluşturulur. Hizmetleriniz, çağrıları daha genel amaçlı bir arka uç hizmet katmanına birleştirerek yazılan "arka uç" sınıflarının "ön ucu" olur, örneğin bir J2EE sunucu kümesi olarak uygulanır. Bu tür bir mimari, arka uç hizmetlerinizin HTTP sunucunuzdan fiziksel olarak ayrı bir bilgisayarda çalışmasını istiyorsanız uygundur. "

Ayrıca, tek bir RequestFactory hizmeti kurmanın 6 civarı java sınıfı oluşturmayı gerektirdiğini ve RPC'nin sadece 3 gerektirdiğini unutmayın. Daha fazla kod == kitabımda daha fazla hata ve karmaşıklık.

RequestFactory, veri proxy'leri ve gerçek java modelleri arasında serileştirmeyi sıralamak zorunda olduğu için, istek işleme sırasında biraz daha fazla ek yüke sahiptir. Eklenen bu arabirim, bir işletme veya üretim ortamında gerçekten toplanabilecek ekstra işlem döngüleri ekler.

Ben de RequestFactory servislerinin RPC servisleri gibi serileştirme olduğuna inanmıyorum.

Sonuçta her ikisini de bir süredir kullandıktan sonra, her zaman RPC'yi daha hafif, test etmesi ve hata ayıklaması daha kolay ve bir RequestFactory kullanarak daha hızlı olduğu için kullanıyorum. RequestFactory daha zarif ve genişletilebilir olsa da, RPC karşı kısmından daha iyidir. Eklenen karmaşıklık, onu daha iyi bir araç gerekli kılmaz.

Bence en iyi mimari, iki web uygulaması, bir istemci ve bir sunucu kullanmaktır. Sunucu, servlet.jar kitaplığını kullanan basit ve hafif bir java web uygulamasıdır. Müşteri GWT'dir. İstemci web uygulamasının sunucu tarafına GWT-RPC aracılığıyla RESTful isteğinde bulunursunuz. İstemcinin sunucu tarafı, sunucu servlet web uygulamanızda tek bir sunucu uygulaması olarak çalıştırdığınız istek işleyicisine kalıcı bir tünel kullanan apache http istemcisine yalnızca bir geçiştir. Servlet web uygulaması, veritabanı uygulama katmanınızı (hazırda bekletme, cayenne, sql vb.) İçermelidir. Bu, veritabanı nesne modellerini gerçek istemciden tamamen ayırmanıza olanak tanır ve uygulamanızı geliştirmek ve birim testi yapmak için çok daha genişletilebilir ve sağlam bir yol sağlar. Biraz ilk kurulum süresi gerektirdiği için, ancak sonunda GWT'nin dışında oturan dinamik bir istek fabrikası oluşturmanıza olanak tanır. Bu, her iki dünyanın en iyilerinden yararlanmanıza olanak tanır. Gwt istemcisinin derlenmesine veya oluşturulmasına gerek kalmadan sunucu tarafınızda değişiklik yapabilmenizden bahsetmiyorum bile.


0

İstemci tarafında ağır bir pojo varsa, örneğin Hibernate veya JPA varlıkları kullanıyorsanız, bunun gerçekten yararlı olduğunu düşünüyorum. Çok hafif varlıklara sahip Django tarzı bir kalıcılık çerçevesi kullanarak başka bir çözümü benimsedik.


0

Yapacağım tek uyarı, RequestFactory'nin normal GWT-RPC'yi değil ikili veri aktarımını (belki deRPC?) Kullanmasıdır.

Bu yalnızca SyncProxy, Jmeter, Fiddler veya HTTP isteğinin / yanıtının içeriğini okuyabilen / değerlendirebilen (GWT-RPC gibi) ancak deRPC veya RequestFactory ile daha zorlayıcı olan benzer bir araçla yoğun testler yapıyorsanız önemlidir.


1
Bunun dışında RequestFactory, SyncProxy gibi 3. parti araçlara ihtiyaç duymadan "saf Java" uygulamasını kutudan çıkarır. Stackoverflow.com/questions/4853188/… sayfasına
Thomas Broyer

0

Projemizde çok geniş bir GWT-RPC uygulamasına sahibiz. Aslında, her biri birçok yönteme sahip 50 Servis arabirimimiz var ve JS kodumuzu çok büyük yapan derleyici tarafından üretilen TypeSerializer boyutlarıyla ilgili sorunlarımız var. Bu yüzden RequestFactory'ye geçmek için analiz yapıyoruz. Birkaç gündür internete girip diğer insanların ne yaptığını bulmaya çalışıyorum. Gördüğüm ve belki de yanılmış olabileceğim en önemli dezavantaj, RequestFactory ile artık Sunucu Etki Alanı nesneleriniz ile istemciniz arasındaki iletişimi kontrol edemeyeceğinizdir. İhtiyacımız olan şey, yükle / kaydet modelini kontrollü bir şekilde uygulamaktır. Demek istediğim, örneğin müşteri belirli bir işleme ait nesnelerin tüm nesne grafiğini alır, güncellemelerini yapar ve tümünü sunucuya geri gönderir. Sunucu, doğrulama yapmaktan, eskiyi yeni değerlerle karşılaştırmaktan ve ısrar etmekten sorumlu olacaktır. Farklı sitelerden 2 kullanıcı aynı işlemi alır ve bazı güncellemeler yaparsa, ortaya çıkan işlem birleştirilmiş işlem olmamalıdır. Güncellemelerden biri senaryomda başarısız olmalı. RequestFactory'nin bu tür işlemleri desteklemeye yardımcı olduğunu görmüyorum.

Saygılarımızla Daniel


Bu endişeleri paylaşıyorum ... sonunda RF'ye gittiniz mi?
HDave

0

Sınırlı bir MIS uygulamasını düşünürken, diyelim ki 10-20 CRUD'lanabilir iş nesnesi ve her biri ~ 1-10 özellik olan, hangi yolla gidileceğinin kişisel tercihe bağlı olduğunu söylemek doğru mu?

Öyleyse, belki de uygulamanızın nasıl ölçekleneceğini öngörmek, GWT RPC veya RequestFactory rotanızı seçmenin anahtarı olabilir:

  1. Başvurumun nispeten sınırlı sayıda kuruluşla kalması bekleniyor, ancak sayıları açısından büyük ölçüde artacak. 10-20 nesne * 100.000 kayıt.

  2. Başvurum varlıkların genişliğinde önemli ölçüde artacak, ancak her birinin dahil olduğu göreceli sayılar düşük kalacaktır. 5000 nesne * 100 kayıt.

  3. Başvurumun nispeten sınırlı sayıda varlıkla kalması ve nispeten düşük sayılarda, örneğin 10-20 nesne * 100 kayıtta kalması bekleniyor

Benim durumumda, bu kararı vermeye çalışmanın tam başlangıç ​​noktasındayım. UI istemci tarafı mimarisini değiştirmenin yanı sıra taşıma seçimini yapmak zorunda kalındığında daha da karmaşıktır. Önceki (önemli ölçüde) büyük ölçekli GWT kullanıcı arabirimim, GWT MVP tesisleri tarafından değiştirilen Hmvc4Gwt kitaplığını kullanıyordu.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.