Kapan saya harus menggunakan RequestFactory vs GWT-RPC?

Saya mencoba untuk mencari tahu apakah saya harus memigrasi panggilan gwt-rpc saya ke panggilan GWT2.1 RequestFactory yang baru.

Dokumentasi Google secara samar menyebutkan bahwa RequestFactory adalah metode komunikasi server-klien yang lebih baik untuk "layanan berorientasi data"

Apa yang dapat saya saring dari dokumentasi adalah bahwa ada kelas Proxy baru yang menyederhanakan komunikasi (Anda tidak bolak-balik entitas sebenarnya tetapi hanya proxy, sehingga bobotnya lebih ringan dan lebih mudah dikelola)

Apakah itu intinya atau apakah saya melewatkan sesuatu yang lain dalam gambaran besar?

Perbedaan besar antara GWT RPC dan RequestFactory adalah bahwa sistem RPC adalah "RPC-by-concrete-type" sedangkan RequestFactory adalah "RPC-by-interface".

RPC lebih mudah digunakan untuk memulai, karena Anda menulis lebih sedikit baris kode dan menggunakan kelas yang sama pada klien dan server. Anda dapat membuat Personkelas dengan sekelompok getter dan setter dan mungkin beberapa logika bisnis sederhana untuk lebih lanjut mengiris-dan-memotong data dalam Personobjek. Ini berfungsi cukup baik sampai Anda akhirnya ingin memiliki kode khusus server, tidak kompatibel dengan GWT, di dalam kelas Anda. Karena sistem RPC didasarkan pada jenis konkret yang sama pada klien dan server, Anda dapat mencapai dinding kompleksitas berdasarkan kapabilitas klien GWT Anda.

Untuk menghindari penggunaan kode yang tidak kompatibel, banyak pengguna akhirnya membuat rekan PersonDTOyang membayangi Personobjek nyata yang digunakan di server. The PersonDTOhanya memiliki subset dari getter dan setter dari server-side, "domain", Personobjek. Sekarang Anda harus menulis kode yang Marshall data antara Persondan PersonDTOobjek dan semua jenis objek lain yang Anda ingin lolos ke klien.

RequestFactory dimulai dengan mengasumsikan bahwa objek domain Anda tidak akan kompatibel dengan GWT. Anda cukup mendeklarasikan properti yang harus dibaca dan ditulis oleh kode klien dalam antarmuka Proxy, dan komponen server RequestFactory menangani penyusunan data dan pemanggilan metode layanan Anda. Untuk aplikasi yang memiliki konsep "Entitas" atau "Objek dengan identitas dan versi" yang terdefinisi dengan baik, EntityProxyjenis ini digunakan untuk mengekspos semantik identitas persisten dari data Anda ke kode klien. Objek sederhana dipetakan menggunakan ValueProxytipe.

Dengan RequestFactory, Anda membayar biaya mulai di muka untuk mengakomodasi sistem yang lebih rumit daripada yang mudah didukung oleh GWT RPC. RequestFactory ServiceLayermenyediakan lebih banyak hook secara signifikan untuk menyesuaikan perilakunya dengan menambahkan ServiceLayerDecoratorinstance.

Saya mengalami transisi dari RPC ke RF. Pertama, saya harus mengatakan pengalaman saya terbatas dalam hal itu, saya menggunakan EntityProxies sebanyak 0.

Keuntungan dari GWT RPC:

• Sangat mudah untuk menyiapkan, memahami, dan BELAJAR!
• Objek berbasis kelas yang sama digunakan di klien dan di server.
• Pendekatan ini menghemat banyak sekali kode.
• Ideal, ketika objek model yang sama (dan POJOS) digunakan pada klien dan server, POJOs == MODEL OBJECTs == DTOs
• Mudah untuk memindahkan barang dari server ke klien.
• Mudah untuk berbagi implementasi logika umum antara klien dan server (ini bisa berubah menjadi kerugian kritis ketika Anda membutuhkan logika yang berbeda).

Kerugian dari GWT RPC:

• Tidak mungkin memiliki implementasi yang berbeda dari beberapa metode untuk server dan klien, misalnya Anda mungkin perlu menggunakan kerangka kerja logging yang berbeda pada klien dan server, atau metode yang sama.
• Implementasi yang BENAR-BENAR BURUK yang tidak dapat dikembangkan lebih lanjut: sebagian besar fungsionalitas server diimplementasikan sebagai metode statis pada kelas RPC. ITU BENAR-BENAR MENGUNTUNGKAN.
• misalnya, tidak mungkin menambahkan kebingungan kesalahan sisi server
• Beberapa masalah keamanan XSS yang tidak dapat dipecahkan dengan cukup elegan, lihat dokumen (Saya tidak yakin apakah ini lebih elegan untuk RequestFactory)

Kekurangan RequestFactory:

• SANGAT SULIT untuk dipahami dari dokumen resmi, apa manfaatnya! Ini dimulai tepat pada istilah PROXIES yang menyesatkan - ini sebenarnya adalah DTO RF yang dibuat oleh RF secara otomatis. Proksi ditentukan oleh antarmuka, misalnya @ProxyFor (Journal.class). IDE memeriksa apakah ada metode yang sesuai di Jurnal. Begitu banyak untuk pemetaan.
• RF tidak akan berbuat banyak untuk Anda dalam hal kesamaan klien dan server karena
• Pada klien, Anda perlu mengonversi "PROXIES" menjadi objek domain klien Anda dan sebaliknya. Ini sangat konyol. Itu bisa dilakukan dalam beberapa baris kode secara deklaratif, tapi TIDAK ADA DUKUNGAN UNTUK ITU! Jika saja kita bisa memetakan objek domain kita ke proxy dengan lebih elegan, sesuatu seperti metode JavaScript JSON.stringify (.. ,,) HILANG di toolbox RF.
• Jangan lupa Anda juga bertanggung jawab untuk menyetel properti yang dapat ditransfer dari objek domain Anda ke proxy, dan seterusnya secara rekursif.
• PENANGANAN KESALAHAN BURUK di server dan - Stack-traces dihilangkan secara default di server dan Anda mendapatkan pengecualian kosong yang tidak berguna di klien. Bahkan ketika saya menyetel penangan kesalahan khusus, saya tidak bisa mendapatkan pelacakan tumpukan tingkat rendah! Mengerikan.
• Beberapa bug minor dalam dukungan IDE dan di tempat lain. Saya mengajukan dua permintaan bug yang diterima. Bukan seorang Einstein yang diperlukan untuk mengetahui bahwa itu sebenarnya serangga.
• DOKUMENTASI SUCKS. Seperti yang saya sebutkan proxy harus dijelaskan lebih baik, istilahnya MENYESATKAN. Untuk masalah umum dasar, yang saya selesaikan, DOC TIDAK BERGUNA. Contoh kesalahpahaman lain dari DOC adalah koneksi anotasi JPA ke RF. Kelihatannya dari dokumen ringkas bahwa mereka bermain bersama, dan ya, ada pertanyaan terkait di StackOverflow. Saya sarankan untuk melupakan 'koneksi' JPA sebelum memahami RF.

Keuntungan dari RequestFactory

• Dukungan forum yang sangat baik.
• Dukungan IDE cukup bagus (tetapi tidak menguntungkan jika dibandingkan dengan RPC)
• Fleksibilitas implementasi klien dan server Anda (kopling longgar)
• Hal-hal mewah, terhubung ke EntityProxies, di luar DTO sederhana - caching, pembaruan parsial, sangat berguna untuk seluler.
• Anda dapat menggunakan ValueProxies sebagai pengganti paling sederhana untuk DTO (tetapi Anda harus melakukan sendiri semua konversi yang tidak terlalu mewah).
• Dukungan untuk Validasi Bean JSR-303.

Mempertimbangkan kerugian lain dari GWT secara umum:

• Tidak mungkin menjalankan tes integrasi (kode klien GWT + server jarak jauh) dengan dukungan JUnit yang disediakan <= semua JSNI harus diolok-olok (misalnya penyimpanan lokal), SOP adalah masalah.

• Tidak ada dukungan untuk penyiapan pengujian - browser tanpa kepala + server jarak jauh <= tidak ada pengujian tanpa kepala sederhana untuk GWT, SOP.

• Ya, dimungkinkan untuk menjalankan tes integrasi selenium (tapi bukan itu yang saya inginkan)

• JSNI sangat kuat, tetapi pada pembicaraan berkilau yang mereka berikan di konferensi, mereka tidak berbicara banyak tentang bahwa menulis kode JSNI juga memiliki beberapa aturan. Sekali lagi, mencari tahu bagaimana menulis panggilan balik sederhana adalah tugas peneliti sejati.

Singkatnya, transisi dari GWT RPC ke RequestFactory jauh dari situasi WIN-WIN, ketika RPC sangat sesuai dengan kebutuhan Anda. Anda akhirnya menulis banyak sekali konversi dari objek domain klien ke proxy dan sebaliknya. Tetapi Anda mendapatkan beberapa fleksibilitas dan ketahanan dari solusi Anda. Dan dukungan di forum ini luar biasa, pada hari Sabtu juga!

Mempertimbangkan semua keuntungan dan kerugian yang baru saja saya sebutkan, ada baiknya untuk memikirkan terlebih dahulu apakah salah satu dari pendekatan ini benar-benar membawa perbaikan pada solusi Anda dan pengaturan pengembangan Anda tanpa pengorbanan besar.

Saya menemukan ide membuat kelas Proxy untuk semua entitas saya cukup menjengkelkan. Pojo Hibernate / JPA saya dihasilkan secara otomatis dari model database. Mengapa sekarang saya perlu membuat mirror kedua untuk RPC? Kami memiliki kerangka "estivation" yang bagus yang menangani "de-hibernasi" pojos.

Juga, gagasan untuk mendefinisikan antarmuka layanan yang tidak cukup mengimplementasikan layanan sisi server sebagai kontrak java tetapi menerapkan metode - terdengar sangat J2EE 1.x / 2.x bagi saya.

Tidak seperti RequestFactory yang memiliki kemampuan penanganan dan pengujian error yang buruk (karena memproses sebagian besar hal di bawah tenda GWT), RPC memungkinkan Anda menggunakan pendekatan yang lebih berorientasi layanan. RequestFactory mengimplementasikan pendekatan gaya injeksi dependensi yang lebih modern yang dapat memberikan pendekatan yang berguna jika Anda perlu memanggil struktur data polimorfik yang kompleks. Saat menggunakan RPC, struktur data Anda harus lebih datar, karena ini akan memungkinkan utilitas marshaling Anda menerjemahkan antara model json / xml dan java Anda. Menggunakan RPC juga memungkinkan Anda mengimplementasikan arsitektur yang lebih kuat, seperti dikutip dari bagian gwt dev di situs Google.

"Penerapan Klien / Server Sederhana

Cara pertama dan paling mudah untuk memikirkan definisi layanan adalah memperlakukannya sebagai keseluruhan backend aplikasi Anda. Dari perspektif ini, kode sisi klien adalah "ujung depan" Anda dan semua kode layanan yang berjalan di server adalah "ujung belakang". Jika Anda menggunakan pendekatan ini, implementasi layanan Anda akan cenderung menjadi API tujuan umum yang tidak digabungkan erat ke satu aplikasi tertentu. Definisi layanan Anda kemungkinan besar akan mengakses database secara langsung melalui JDBC atau Hibernate atau bahkan file dalam sistem file server. Untuk banyak aplikasi, tampilan ini sesuai, dan bisa sangat efisien karena mengurangi jumlah tingkatan.

Penerapan Multi-Tingkat

Dalam arsitektur multi-tingkat yang lebih kompleks, definisi layanan GWT Anda dapat berupa gateway ringan yang memanggil lingkungan server back-end seperti server J2EE. Dari perspektif ini, layanan Anda dapat dilihat sebagai "setengah server" dari antarmuka pengguna aplikasi Anda. Alih-alih ditujukan untuk tujuan umum, layanan dibuat untuk kebutuhan khusus antarmuka pengguna Anda. Layanan Anda menjadi kelas "ujung depan" ke kelas "ujung belakang" yang ditulis dengan menggabungkan panggilan ke lapisan layanan ujung belakang yang lebih umum, diimplementasikan, misalnya, sebagai kumpulan server J2EE. Jenis arsitektur ini sesuai jika Anda memerlukan layanan back-end untuk dijalankan di komputer yang terpisah secara fisik dari server HTTP Anda. "

Juga perhatikan bahwa menyiapkan layanan RequestFactory tunggal membutuhkan pembuatan sekitar 6 atau lebih kelas java dimana RPC hanya membutuhkan 3. Lebih banyak kode == lebih banyak kesalahan dan kompleksitas dalam buku saya.

RequestFactory juga memiliki sedikit lebih banyak overhead selama pemrosesan permintaan, karena ia harus mengatur serialisasi antara proxy data dan model java yang sebenarnya. Antarmuka tambahan ini menambahkan siklus pemrosesan ekstra yang benar-benar dapat bertambah di lingkungan perusahaan atau produksi.

Saya juga tidak percaya bahwa layanan RequestFactory adalah serialisasi seperti layanan RPC.

Semua dalam semua setelah menggunakan keduanya untuk beberapa waktu sekarang, saya selalu menggunakan RPC karena lebih ringan, lebih mudah untuk menguji dan debug, dan lebih cepat kemudian menggunakan RequestFactory. Meskipun RequestFactory mungkin lebih elegan dan dapat diperluas daripada bagian RPC-nya. Kompleksitas tambahan tidak membuatnya menjadi alat yang lebih baik.

Pendapat saya adalah bahwa arsitektur terbaik adalah menggunakan dua aplikasi web, satu klien dan satu server. Server adalah aplikasi web java umum ringan sederhana yang menggunakan perpustakaan servlet.jar. Kliennya adalah GWT. Anda membuat permintaan RESTful melalui GWT-RPC ke sisi server aplikasi web klien. Sisi server klien hanyalah sebuah pass untuk apache http klien yang menggunakan terowongan persisten ke penangan permintaan yang Anda jalankan sebagai satu servlet di aplikasi web server servlet Anda. Aplikasi web servlet harus berisi lapisan aplikasi database Anda (hibernate, cayenne, sql dll ..). Hal ini memungkinkan Anda untuk sepenuhnya memisahkan model objek database dari klien sebenarnya, menyediakan cara yang jauh lebih dapat diperluas dan kuat untuk mengembangkan dan menguji unit aplikasi Anda. Memang membutuhkan sedikit waktu penyiapan awal, tetapi pada akhirnya memungkinkan Anda untuk membuat pabrik permintaan dinamis yang berada di luar GWT. Ini memungkinkan Anda memanfaatkan yang terbaik dari kedua dunia. Belum lagi dapat menguji dan membuat perubahan pada sisi server Anda tanpa harus mengkompilasi atau membangun klien gwt.

Saya pikir itu sangat membantu jika Anda memiliki pojo berat di sisi klien, misalnya jika Anda menggunakan entitas Hibernate atau JPA. Kami mengadopsi solusi lain, menggunakan kerangka ketekunan gaya Django dengan entitas yang sangat ringan.

Satu-satunya peringatan yang akan saya masukkan adalah bahwa RequestFactory menggunakan transportasi data biner (mungkin deRPC?) Dan bukan GWT-RPC normal.

Ini hanya penting jika Anda melakukan pengujian berat dengan SyncProxy, Jmeter, Fiddler, atau fitur serupa yang dapat membaca / mengevaluasi konten permintaan / respons HTTP (seperti GWT-RPC), tetapi akan lebih menantang dengan deRPC atau RequestFactory.

Kami memiliki implementasi GWT-RPC yang sangat besar dalam proyek kami. Sebenarnya kami memiliki 50 antarmuka Layanan dengan masing-masing banyak metode, dan kami memiliki masalah dengan ukuran TypeSerializers yang dihasilkan oleh kompilator yang mengubah kode JS kami menjadi besar. Jadi kami menganalisis untuk bergerak menuju RequestFactory. Saya telah membaca selama beberapa hari untuk menggali web dan mencoba menemukan apa yang dilakukan orang lain. Kelemahan terpenting yang saya lihat, dan mungkin saya salah, adalah bahwa dengan RequestFactory, Anda tidak lagi mengontrol komunikasi antara objek Domain Server dan klien Anda. Yang kita butuhkan adalah menerapkan pola muat / simpan secara terkontrol. Maksud saya, misalnya klien menerima seluruh objek grafik dari objek yang termasuk dalam transaksi tertentu, melakukan pembaruannya dan mereka mengirim keseluruhan kembali ke server. Server akan bertanggung jawab untuk melakukan validasi, membandingkan nilai lama dengan nilai baru dan melakukan persistensi. Jika 2 pengguna dari situs berbeda mendapatkan transaksi yang sama dan melakukan beberapa pembaruan, transaksi yang dihasilkan tidak boleh menjadi transaksi gabungan. Salah satu pembaruan harus gagal dalam skenario saya. Saya tidak melihat bahwa RequestFactory membantu mendukung pemrosesan semacam ini.

Salam Daniel

Apakah adil untuk mengatakan bahwa ketika mempertimbangkan aplikasi SIM terbatas, katakanlah dengan 10-20 objek bisnis yang dapat CRUD, dan masing-masing dengan ~ 1-10 properti, itu benar-benar tergantung pada preferensi pribadi rute mana yang akan digunakan?

Jika demikian, maka mungkin memproyeksikan bagaimana aplikasi Anda akan diskalakan bisa menjadi kunci dalam memilih rute GWT RPC atau RequestFactory:

1. Aplikasi saya diharapkan untuk tetap dengan jumlah entitas yang relatif terbatas tetapi akan meningkat secara besar-besaran dalam hal jumlah mereka. 10-20 objek * 100.000 catatan.

2. Aplikasi saya akan meningkat secara signifikan dalam luasnya entitas tetapi jumlah relatif yang terlibat masing-masing akan tetap rendah. 5000 objek * 100 catatan.

3. Aplikasi saya diharapkan untuk tetap dengan jumlah entitas yang relatif terbatas DAN akan tetap dalam jumlah yang relatif rendah misalnya 10-20 objek * 100 catatan

Dalam kasus saya, saya berada di titik paling awal untuk mencoba membuat keputusan ini. Lebih rumit lagi dengan harus mengubah arsitektur sisi klien UI serta membuat pilihan transportasi. UI GWT skala besar saya sebelumnya (secara signifikan) menggunakan pustaka Hmvc4Gwt, yang telah digantikan oleh fasilitas GWT MVP.