ฉันกำลังพยายามคิดว่าฉันควรย้ายการเรียก gwt-rpc ของฉันไปยัง cals RequestFactory GWT2.1 ใหม่หรือไม่
เอกสารของ Google ระบุอย่างคลุมเครือว่า RequestFactory เป็นวิธีการสื่อสารไคลเอนต์เซิร์ฟเวอร์ที่ดีกว่าสำหรับ "บริการที่มุ่งเน้นข้อมูล"
สิ่งที่ฉันสามารถกลั่นได้จากเอกสารคือมีคลาส Proxy ใหม่ที่ทำให้การสื่อสารง่ายขึ้น (คุณไม่ได้ส่งผ่านเอนทิตีจริงไปมา แต่เป็นเพียงพร็อกซีดังนั้นจึงมีน้ำหนักเบากว่าและจัดการได้ง่ายกว่า)
นั่นคือจุดรวมหรือฉันพลาดอย่างอื่นในภาพรวม?
คำตอบ:
ความแตกต่างที่สำคัญระหว่าง GWT RPC และ RequestFactory คือระบบ RPC เป็น "RPC-by-Concrete-type" ในขณะที่ RequestFactory คือ "RPC-by-interface"
RPC สะดวกกว่าในการเริ่มต้นเนื่องจากคุณเขียนโค้ดน้อยลงและใช้คลาสเดียวกันทั้งในไคลเอนต์และเซิร์ฟเวอร์ คุณอาจสร้างPersonคลาสที่มี getters และ setters จำนวนมากและอาจใช้ตรรกะทางธุรกิจง่ายๆสำหรับการแบ่งส่วนข้อมูลเพิ่มเติมในPersonออบเจ็กต์ สิ่งนี้ใช้งานได้ดีจนกว่าคุณจะเลิกต้องการมีรหัสเฉพาะเซิร์ฟเวอร์ที่ไม่เข้ากันได้กับ GWT ในชั้นเรียนของคุณ เนื่องจากระบบ RPC ขึ้นอยู่กับการมีคอนกรีตประเภทเดียวกันทั้งในไคลเอนต์และเซิร์ฟเวอร์คุณจึงสามารถตีกำแพงความซับซ้อนตามความสามารถของไคลเอ็นต์ GWT ของคุณ
เพื่อหลีกเลี่ยงการใช้รหัสที่เข้ากันไม่ได้ผู้ใช้หลายคนต้องสร้างเพียร์PersonDTOที่เงาPersonวัตถุจริงที่ใช้บนเซิร์ฟเวอร์ PersonDTOมีเพียงส่วนย่อยของ getters และ setters ของฝั่งเซิร์ฟเวอร์ "โดเมน" Personวัตถุ ตอนนี้คุณต้องเขียนโค้ดที่ข้อมูลมาร์แชลระหว่างPersonและPersonDTOวัตถุและทุกประเภทวัตถุอื่น ๆ ที่คุณต้องการที่จะผ่านไปยังลูกค้า
RequestFactory เริ่มต้นโดยสมมติว่าวัตถุโดเมนของคุณจะไม่เข้ากันได้กับ GWT คุณเพียงแค่ประกาศคุณสมบัติที่โค้ดไคลเอ็นต์ควรอ่านและเขียนในอินเทอร์เฟซ Proxy และส่วนประกอบเซิร์ฟเวอร์ RequestFactory จะดูแลการจัดเก็บข้อมูลและเรียกใช้วิธีการบริการ สำหรับแอปพลิเคชันที่มีแนวคิด "เอนทิตี" หรือ "อ็อบเจ็กต์ที่มีข้อมูลประจำตัวและเวอร์ชัน" ที่กำหนดไว้อย่างชัดเจนEntityProxyประเภทจะใช้เพื่อแสดงความหมายของข้อมูลประจำตัวของข้อมูลของคุณกับโค้ดไคลเอ็นต์ แมปวัตถุอย่างง่ายโดยใช้ValueProxyชนิด
ด้วย RequestFactory คุณจ่ายค่าเริ่มต้นล่วงหน้าเพื่อรองรับระบบที่ซับซ้อนมากกว่าที่ GWT RPC รองรับได้อย่างง่ายดาย RequestFactory ServiceLayerมี hooks มากขึ้นอย่างมากในการปรับแต่งพฤติกรรมโดยการเพิ่มServiceLayerDecoratorอินสแตนซ์
ฉันผ่านการเปลี่ยนจาก RPC เป็น RF ก่อนอื่นฉันต้องบอกว่าประสบการณ์ของฉันมี จำกัด ฉันใช้ EntityProxies มากถึง 0
ข้อดีของ GWT RPC:
Disadvatages ของ GWT RPC:
ข้อเสียของ RequestFactory:
ข้อดีของ RequestFactory
พิจารณาข้อเสียอื่น ๆ ของ GWT โดยทั่วไป:
เป็นไปไม่ได้ที่จะเรียกใช้การทดสอบการรวม (รหัสไคลเอ็นต์ GWT + เซิร์ฟเวอร์ระยะไกล) ด้วยการสนับสนุน JUnit ที่จัดเตรียมไว้ให้ <= JSNI ทั้งหมดจะต้องถูกจำลอง (เช่น localStorage) SOP เป็นปัญหา
ไม่รองรับการตั้งค่าการทดสอบ - เบราว์เซอร์ไร้หัว + เซิร์ฟเวอร์ระยะไกล <= ไม่มีการทดสอบแบบไร้หัวง่ายๆสำหรับ GWT, SOP
ใช่มันเป็นไปได้ที่จะทำการทดสอบการรวมซีลีเนียม (แต่นั่นไม่ใช่สิ่งที่ฉันต้องการ)
JSNI มีประสิทธิภาพมาก แต่ในการพูดคุยที่เป็นประกายพวกเขาให้ในการประชุมพวกเขาไม่ได้พูดถึงมากนักเกี่ยวกับการเขียนโค้ด JSNI นั้นมีกฎบางอย่างด้วย อีกครั้งการหาวิธีเขียนคำเรียกกลับง่ายๆเป็นงานที่คุ้มค่าสำหรับนักวิจัยที่แท้จริง
โดยสรุปการเปลี่ยนจาก GWT RPC เป็น RequestFactory อยู่ไกลจากสถานการณ์ WIN-WIN เมื่อ RPC ตรงกับความต้องการของคุณเป็นส่วนใหญ่ คุณจบลงด้วยการเขียนการแปลงจำนวนมากจากอ็อบเจ็กต์โดเมนไคลเอนต์ไปยังพร็อกซีและในทางกลับกัน แต่คุณจะได้รับความยืดหยุ่นและความแข็งแกร่งในการแก้ปัญหาของคุณ และการสนับสนุนในฟอรัมก็ยอดเยี่ยมในวันเสาร์เช่นกัน!
เมื่อพิจารณาถึงข้อดีและข้อเสียทั้งหมดที่ฉันได้กล่าวไปแล้วการคิดล่วงหน้าว่าแนวทางใด ๆ เหล่านี้จะช่วยปรับปรุงโซลูชันของคุณได้จริงหรือไม่และในการตั้งค่าการพัฒนาของคุณโดยไม่ต้องเสียเปรียบครั้งใหญ่
ฉันพบว่าแนวคิดในการสร้างคลาส Proxy สำหรับเอนทิตีทั้งหมดของฉันค่อนข้างน่ารำคาญ My Hibernate / JPA pojos สร้างขึ้นโดยอัตโนมัติจากโมเดลฐานข้อมูล ทำไมตอนนี้ฉันต้องสร้างมิเรอร์ที่สองสำหรับ RPC เรามีกรอบ "การเพิ่มคุณค่า" ที่ดีที่จะดูแล "การจำศีล" ของ pojos
นอกจากนี้แนวคิดในการกำหนดอินเทอร์เฟซบริการที่ไม่ค่อยใช้บริการฝั่งเซิร์ฟเวอร์เป็นสัญญา java แต่ใช้วิธีการ - ฟังดู J2EE 1.x / 2.x มากสำหรับฉัน
ซึ่งแตกต่างจาก RequestFactory ซึ่งมีความสามารถในการจัดการและทดสอบข้อผิดพลาดที่ไม่ดี (เนื่องจากมันประมวลผลสิ่งต่างๆส่วนใหญ่ภายใต้ประทุนของ GWT) RPC ช่วยให้คุณใช้วิธีการที่มุ่งเน้นบริการได้มากขึ้น RequestFactory ใช้วิธีการฉีดขึ้นรูปแบบพึ่งพาที่ทันสมัยมากขึ้นซึ่งสามารถให้แนวทางที่เป็นประโยชน์หากคุณต้องการเรียกใช้โครงสร้างข้อมูลโพลีมอร์ฟิกที่ซับซ้อน เมื่อใช้ RPC โครงสร้างข้อมูลของคุณจะต้องแบนมากขึ้นเนื่องจากจะทำให้ยูทิลิตี้การจัดระเบียบของคุณสามารถแปลระหว่างโมเดล json / xml และ java ของคุณได้ การใช้ RPC ยังช่วยให้คุณสามารถใช้สถาปัตยกรรมที่มีประสิทธิภาพมากขึ้นตามที่ยกมาจากส่วน gwt dev บนเว็บไซต์ของ Google
"การปรับใช้ไคลเอนต์ / เซิร์ฟเวอร์อย่างง่าย
วิธีแรกและตรงไปตรงมาที่สุดในการนึกถึงคำจำกัดความของบริการคือการถือว่าเป็นส่วนหลังทั้งหมดของแอปพลิเคชันของคุณ จากมุมมองนี้รหัสฝั่งไคลเอ็นต์คือ "ส่วนหน้า" ของคุณและรหัสบริการทั้งหมดที่ทำงานบนเซิร์ฟเวอร์คือ "ส่วนหลัง" หากคุณใช้แนวทางนี้การติดตั้งบริการของคุณมีแนวโน้มที่จะเป็น API ที่ใช้งานทั่วไปมากกว่าซึ่งไม่ได้เชื่อมโยงอย่างแน่นหนากับแอปพลิเคชันเฉพาะ คำจำกัดความบริการของคุณอาจเข้าถึงฐานข้อมูลโดยตรงผ่าน JDBC หรือ Hibernate หรือแม้แต่ไฟล์ในระบบไฟล์ของเซิร์ฟเวอร์ สำหรับแอปพลิเคชันจำนวนมากมุมมองนี้เหมาะสมและมีประสิทธิภาพมากเนื่องจากลดจำนวนชั้นลง
การปรับใช้หลายชั้น
ในสถาปัตยกรรมแบบหลายชั้นที่ซับซ้อนมากขึ้นคำจำกัดความบริการ GWT ของคุณอาจเป็นเกตเวย์ที่มีน้ำหนักเบาซึ่งเรียกผ่านไปยังสภาพแวดล้อมเซิร์ฟเวอร์ส่วนหลังเช่นเซิร์ฟเวอร์ J2EE จากมุมมองนี้บริการของคุณอาจถูกมองว่าเป็น "ครึ่งเซิร์ฟเวอร์" ของอินเทอร์เฟซผู้ใช้ของแอปพลิเคชันของคุณ แทนที่จะเป็นวัตถุประสงค์ทั่วไปบริการต่างๆจะถูกสร้างขึ้นสำหรับความต้องการเฉพาะของอินเทอร์เฟซผู้ใช้ของคุณ บริการของคุณจะกลายเป็น "ส่วนหน้า" ไปยังคลาส "ส่วนหลัง" ที่เขียนโดยการรวมการเรียกเข้าด้วยกันไปยังชั้นบริการส่วนหลังที่มีวัตถุประสงค์ทั่วไปมากขึ้นซึ่งนำไปใช้งานเช่นเป็นคลัสเตอร์ของเซิร์ฟเวอร์ J2EE สถาปัตยกรรมประเภทนี้เหมาะสมหากคุณต้องการให้บริการส่วนหลังของคุณทำงานบนคอมพิวเตอร์ที่แยกจากเซิร์ฟเวอร์ HTTP ของคุณ "
โปรดทราบว่าการตั้งค่าบริการ RequestFactory เดียวต้องสร้างคลาส java ประมาณ 6 คลาสโดยที่ RPC ต้องการเพียง 3 โค้ดเพิ่มเติม == มีข้อผิดพลาดและความซับซ้อนมากขึ้นในหนังสือของฉัน
RequestFactory ยังมีค่าใช้จ่ายเพิ่มขึ้นอีกเล็กน้อยในระหว่างการประมวลผลคำขอเนื่องจากต้องมีการจัดลำดับแบบอนุกรมระหว่างพร็อกซีข้อมูลและโมเดลจาวาจริง อินเทอร์เฟซที่เพิ่มเข้ามานี้จะเพิ่มรอบการประมวลผลพิเศษซึ่งสามารถเพิ่มขึ้นในสภาพแวดล้อมขององค์กรหรือการผลิต
ฉันไม่เชื่อด้วยว่าบริการ RequestFactory เป็นบริการซีเรียลไลเซชั่นเหมือนบริการ RPC
สรุปแล้วหลังจากใช้ทั้งสองอย่างมาระยะหนึ่งแล้วฉันมักจะไปกับ RPC เนื่องจากมีน้ำหนักเบากว่าทดสอบและดีบักง่ายกว่าและเร็วกว่าโดยใช้ RequestFactory แม้ว่า RequestFactory อาจจะดูหรูหราและขยายได้มากกว่า แต่ส่วนของเคาน์เตอร์ RPC ความซับซ้อนที่เพิ่มเข้ามาไม่ได้ทำให้เป็นเครื่องมือที่ดีกว่าที่จำเป็น
ความเห็นของฉันคือสถาปัตยกรรมที่ดีที่สุดคือการใช้เว็บแอปสองตัวไคลเอนต์หนึ่งเครื่องและเซิร์ฟเวอร์หนึ่งเครื่อง เซิร์ฟเวอร์เป็นเว็บแอป java ทั่วไปที่มีน้ำหนักเบาซึ่งใช้ไลบรารี servlet.jar ไคลเอนต์คือ GWT คุณทำการร้องขอ RESTful ผ่าน GWT-RPC ในฝั่งเซิร์ฟเวอร์ของเว็บแอปพลิเคชันไคลเอนต์ ฝั่งเซิร์ฟเวอร์ของไคลเอ็นต์เป็นเพียงการส่งผ่านไปยังไคลเอ็นต์ apache http ซึ่งใช้ทันเนลที่คงอยู่ในตัวจัดการคำร้องขอที่คุณเรียกใช้เป็น servlet เดียวในเว็บแอ็พพลิเคชันเซิร์ฟเวอร์ แอปพลิเคชันบนเว็บ servlet ควรมีเลเยอร์แอปพลิเคชันฐานข้อมูลของคุณ (hibernate, cayenne, sql และอื่น ๆ ) ซึ่งจะช่วยให้คุณสามารถแยกโมเดลวัตถุฐานข้อมูลออกจากไคลเอนต์จริงได้อย่างเต็มที่โดยให้วิธีที่ขยายได้และมีประสิทธิภาพมากขึ้นในการพัฒนาและทดสอบแอปพลิเคชันของคุณ จริงอยู่ที่มันต้องใช้เวลาในการตั้งค่าเริ่มต้นเล็กน้อย แต่ในท้ายที่สุดคุณสามารถสร้างโรงงานการร้องขอแบบไดนามิกที่อยู่นอก GWT ได้ สิ่งนี้ช่วยให้คุณสามารถใช้ประโยชน์จากสิ่งที่ดีที่สุดของทั้งสองโลกได้ ไม่ต้องพูดถึงความสามารถในการทดสอบและเปลี่ยนแปลงฝั่งเซิร์ฟเวอร์ของคุณโดยไม่ต้องมีไคลเอ็นต์ gwt คอมไพล์หรือสร้าง
ฉันคิดว่ามันมีประโยชน์มากถ้าคุณมี pojo หนักในฝั่งไคลเอ็นต์เช่นถ้าคุณใช้เอนทิตี Hibernate หรือ JPA เรานำโซลูชันอื่นมาใช้โดยใช้กรอบการคงอยู่สไตล์ Django กับเอนทิตีที่เบามาก
ข้อแม้เดียวที่ฉันจะใส่คือ RequestFactory ใช้การขนส่งข้อมูลไบนารี (อาจจะ deRPC?) ไม่ใช่ GWT-RPC ปกติ
สิ่งนี้มีความสำคัญเฉพาะในกรณีที่คุณทำการทดสอบอย่างหนักด้วย SyncProxy, Jmeter, Fiddler หรือเครื่องมือที่คล้ายกันซึ่งสามารถอ่าน / ประเมินเนื้อหาของคำขอ / การตอบกลับ HTTP (เช่น GWT-RPC) แต่จะมีความท้าทายมากกว่าเมื่อใช้ deRPC หรือ RequestFactory
เรามีการนำ GWT-RPC มาใช้ในโครงการของเราเป็นจำนวนมาก จริงๆแล้วเรามีอินเทอร์เฟซบริการ 50 รายการในแต่ละวิธีและเรามีปัญหากับขนาดของ TypeSerializers ที่สร้างโดยคอมไพเลอร์ที่ทำให้โค้ด JS ของเรามีขนาดใหญ่ ดังนั้นเราจึงวิเคราะห์เพื่อมุ่งสู่ RequestFactory ฉันได้รับการอ่านสองสามวันในการขุดค้นเว็บและพยายามค้นหาว่าคนอื่นกำลังทำอะไรอยู่ ข้อเสียเปรียบที่สำคัญที่สุดที่ฉันเห็นและบางทีฉันอาจจะคิดผิดก็คือด้วย RequestFactory คุณไม่ได้ควบคุมการสื่อสารระหว่างอ็อบเจ็กต์ Server Domain และไคลเอนต์ของคุณอีกต่อไป สิ่งที่เราต้องการคือใช้รูปแบบการโหลด / บันทึกในลักษณะควบคุม ฉันหมายถึงเช่นไคลเอนต์ได้รับกราฟออบเจ็กต์ทั้งหมดของออบเจ็กต์ที่เป็นของธุรกรรมเฉพาะทำการอัปเดตของเขาและส่งข้อมูลทั้งหมดกลับไปที่เซิร์ฟเวอร์ เซิร์ฟเวอร์จะรับผิดชอบในการตรวจสอบความถูกต้องเปรียบเทียบค่าเก่ากับค่าใหม่และดำเนินการต่อ หากผู้ใช้ 2 รายจากไซต์ต่างๆได้รับธุรกรรมเดียวกันและทำการอัปเดตบางอย่างธุรกรรมผลลัพธ์ไม่ควรเป็นธุรกรรมที่รวมเข้าด้วยกัน การอัปเดตอย่างใดอย่างหนึ่งควรล้มเหลวในสถานการณ์ของฉัน ฉันไม่เห็นว่า RequestFactory ช่วยสนับสนุนการประมวลผลประเภทนี้
ขอแสดงความนับถือแดเนียล
เป็นเรื่องยุติธรรมหรือไม่ที่จะกล่าวว่าเมื่อพิจารณาถึงแอปพลิเคชัน MIS ที่ จำกัด ให้พูดด้วยวัตถุทางธุรกิจที่สามารถทำได้ 10-20 CRUD และแต่ละรายการมีคุณสมบัติ ~ 1-10 ซึ่งขึ้นอยู่กับความชอบส่วนบุคคลที่จะไปด้วย
ถ้าเป็นเช่นนั้นการคาดการณ์ว่าแอปพลิเคชันของคุณจะปรับขนาดอย่างไรอาจเป็นกุญแจสำคัญในการเลือกเส้นทาง GWT RPC หรือ RequestFactory ของคุณ:
แอปพลิเคชันของฉันคาดว่าจะอยู่กับเอนทิตีที่ค่อนข้าง จำกัด นั้น แต่จะเพิ่มขึ้นอย่างมหาศาลในแง่ของจำนวน 10-20 วัตถุ * 100,000 บันทึก
แอปพลิเคชันของฉันจะเพิ่มขึ้นอย่างมากในความกว้างของเอนทิตี แต่จำนวนสัมพัทธ์ที่เกี่ยวข้องกับแต่ละเอนทิตีจะยังคงต่ำ 5,000 วัตถุ * 100 บันทึก
แอปพลิเคชันของฉันคาดว่าจะอยู่กับเอนทิตีที่ค่อนข้าง จำกัด และจะอยู่ในจำนวนที่ค่อนข้างต่ำเช่น 10-20 วัตถุ * 100 รายการ
ในกรณีของฉันฉันอยู่ในจุดเริ่มต้นของการพยายามตัดสินใจครั้งนี้ ซับซ้อนมากขึ้นโดยต้องเปลี่ยนสถาปัตยกรรมฝั่งไคลเอ็นต์ UI รวมถึงการเลือกการขนส่ง GWT UI ขนาดใหญ่ก่อนหน้าของฉันใช้ไลบรารี Hmvc4Gwt ซึ่งถูกแทนที่โดยสิ่งอำนวยความสะดวก GWT MVP