ข้อดีข้อเสียของเว็บเฟรมเวิร์ก Java แบบต่างๆคืออะไร? [ปิด]

ฉันกำลังพิจารณาสร้างเว็บไซต์ของตัวเองโดยใช้ Java และกำลังพยายามตัดสินใจว่าจะใช้กรอบงานใด อย่างไรก็ตามการค้นหาเฟรมเวิร์ก Java อย่างรวดเร็วมีผลตอบแทนมากกว่า 50 รายการให้เลือก!

เว็บไซต์ของฉันเป็นเพียงเพื่อความเพลิดเพลินของตัวเองในการสร้างมันในตอนแรก แต่ถ้ามันเป็นที่นิยมมันก็จะดีที่จะมีความสามารถในการปรับขนาดได้บ้างหรืออย่างน้อยก็สามารถออกแบบใหม่ได้

อะไรคือความแตกต่างที่สำคัญระหว่างเฟรมเวิร์กที่เป็นที่นิยมมากขึ้น? มีบางกรณีที่มีประสิทธิภาพเหนือกว่ากรณีอื่น ๆ อย่างมีนัยสำคัญหรือไม่? ตัวอย่างเช่นแอปพลิเคชันระดับองค์กรที่มีปริมาณการใช้งานสูงเทียบกับแอปพลิเคชันขนาดเล็กที่มีปริมาณการใช้งานน้อย ฉันยังสงสัยว่าบางอย่างเรียนรู้และใช้งานได้ง่ายกว่าคนอื่น ๆ หรือไม่

มีใครมีประสบการณ์เกี่ยวกับ framework เหล่านี้บ้างช่วยแนะนำหน่อยครับ? จำนวนตัวเลือกที่แท้จริงเป็นเพียงการเตือนล่วงหน้าเพื่อหลีกเลี่ยงการพัฒนาเว็บที่ใช้ Java หากเป็นไปได้หรือไม่?

ฉันใช้Tapestry 3 , Wicket , EchoและJSFค่อนข้างครอบคลุม ฉันขอแนะนำให้คุณดูสิ่งเหล่านั้นและเลือกสิ่งที่ดูเหมือนง่ายที่สุดสำหรับคุณและเหมาะสมกับวิธีการทำงานที่คุณต้องการมากที่สุด

สำหรับพวกเขาสิ่งที่สะดวกสบายที่สุดสำหรับฉันในการทำงานคือWicketเนื่องจากลักษณะการสร้างส่วนประกอบที่มีน้ำหนักเบาและความเรียบง่ายของการทำเทมเพลตเพจ นั่นจะทวีคูณดังนั้นหากคุณใช้รหัส db ของคุณเองแทน Hibernate หรือกรอบงานอื่น ๆ (ฉันไม่เคยพอใจกับ Wicket Hibernate หรือ Spring Integration เลย)

Echoดีมากถ้าคุณไม่คิดจะเขียนเค้าโครงทั้งหมดใน Java ตอนนี้ฉันรู้ว่ามันแตกต่างออกไป แต่ฉันยังคิดว่าผลิตภัณฑ์นั้นให้บริการเฉพาะกลุ่มที่ค่อนข้างแคบ พวกเขาเปลี่ยนรูปแบบการพัฒนาทุก ๆ รุ่นที่สำคัญเช่นกัน

Tapestryเป็นผลิตภัณฑ์ที่ยอดเยี่ยม แต่เห็นได้ชัดว่ามีความแตกต่างจากผลิตภัณฑ์อื่น ๆ ในแง่ของรูปแบบการพัฒนาเนื่องจากนำโดยเพื่อนคนเดียวเป็นหลัก Howard Lewis Ship ไม่ต้องสงสัยเลยว่าค่อนข้างฉลาด แต่ฉันผิดหวังกับการตัดสินใจของพวกเขาที่ลืมความเข้ากันได้แบบย้อนกลับกับแต่ละรุ่น อีกครั้งสำหรับความต้องการของคุณสิ่งนี้อาจไม่สำคัญและฉันพบว่าผลิตภัณฑ์ Tapestry เป็นที่พอใจในการทำงานเสมอ

JSFออกมาหลายปีแล้วและยังคงรู้สึกเหมือนเป็นสิ่งที่Strutsสร้างขึ้นเพื่อแก้ไขปัญหาทั้งหมดของ Struts โดยไม่เข้าใจปัญหาทั้งหมดของ Struts มันยังคงให้ความรู้สึกที่ยังไม่เสร็จแม้ว่าผลิตภัณฑ์จะมีความยืดหยุ่นมากก็ตาม ฉันใช้มันและชื่นชอบมันด้วยความหวังเป็นอย่างยิ่งสำหรับอนาคตของมัน ฉันคิดว่ารุ่นถัดไป (2.0) ที่จะจัดส่งใน JEE6 จะนำมาเป็นของตัวเองจริงๆด้วยไวยากรณ์เทมเพลตใหม่ (คล้ายกับ Facelets) และรูปแบบส่วนประกอบที่เรียบง่าย (ส่วนประกอบที่กำหนดเองใน 1 ไฟล์เท่านั้น ... ในที่สุด)

และแน่นอนว่ามีเฟรมเวิร์กและเครื่องมือขนาดเล็กกว่าล้านรายการที่ได้รับสิ่งต่อไปนี้ ( Velocityสำหรับความต้องการขั้นพื้นฐาน, JSPs แบบดิบ, Struts ฯลฯ ) โดยทั่วไปฉันชอบเฟรมเวิร์กที่เน้นองค์ประกอบด้วยตัวเอง

ท้ายที่สุดฉันขอแนะนำให้ลองดู Tapestry, Wicket และ JSF แล้วเลือกสิ่งที่รู้สึกดีที่สุดสำหรับคุณ คุณอาจจะพบสิ่งที่เหมาะกับวิธีที่คุณต้องการทำงานอย่างรวดเร็ว

ที่ฉันชอบคือ Spring Framework ด้วย 2.5 Spring MVC คือการเตะที่ยอดเยี่ยมพร้อมคำอธิบายประกอบใหม่การประชุมผ่านคุณสมบัติการกำหนดค่า ฯลฯ

หากคุณกำลังทำสิ่งที่ง่ายสุด ๆ คุณสามารถลองใช้ Servlet API ปกติและไม่ต้องกังวลกับกรอบงาน

ฉันขอแนะนำเฟรมเวิร์กWicket ที่เน้นองค์ประกอบ ช่วยให้คุณสามารถเขียนเว็บแอปพลิเคชันของคุณด้วยโค้ด Java แบบเก่าคุณสามารถใช้ POJO เป็นโมเดลสำหรับส่วนประกอบทั้งหมดและไม่จำเป็นต้องยุ่งกับไฟล์คอนฟิกูเรชัน XML ขนาดใหญ่

ฉันประสบความสำเร็จในการพัฒนาแอปพลิเคชันธนาคารออนไลน์กับ Struts เมื่อฉันค้นพบ Wicket และเห็นว่าการพัฒนาแอปพลิเคชันบนเว็บนั้นง่ายแค่ไหน!

ฉันเพิ่งเริ่มใช้ไฟล์ Stripes Frameworkลายเส้นกรอบหากคุณกำลังมองหาเฟรมเวิร์กตามคำขอที่ใช้งานง่าย แต่ไม่ได้กำหนดข้อ จำกัด ใด ๆ เกี่ยวกับสิ่งที่คุณกำลังทำฉันขอแนะนำเป็นอย่างยิ่ง

มันคล้ายกับเสา แต่มันไปไกลกว่านั้น มีแม้แต่โปรเจ็กต์ปลั๊กอินบางโปรเจ็กต์ที่ให้คุณใช้ไฮเบอร์เนตหรือ jpa โดยมีการกำหนดค่าน้อยมาก

มีกรอบที่ดีมากมายอยู่ที่นั่นแม้ว่าฉันจะเคยได้ยินมาว่าประตูก็เป็นประตูที่ดีเช่นกัน แต่ฉันไม่ได้ใช้มัน

ยังไม่ได้ลองเอง แต่คิดว่า

http://www.playframework.org/

มีศักยภาพมาก ...

มาจาก php และ classic asp มันเป็นเว็บเฟรมเวิร์ก java ตัวแรกที่สัญญากับฉัน ....

อัปเดต: Tapestry 5.2 หมดแล้วดังนั้นจึงไม่ถูกทิ้งอย่างที่เคยเป็นมา ประสบการณ์ของฉันคือ Tapestry 4 ไม่ใช่ 5 ดังนั้นระยะทางของคุณอาจแตกต่างกันไป ความคิดเห็นของฉันเกี่ยวกับ Tapestry ได้เปลี่ยนไปในช่วงหลายปีที่ผ่านมา ฉันได้แก้ไขโพสต์นี้เพื่อให้สอดคล้องกับมัน

ฉันไม่สามารถแนะนำ Tapestry เหมือนที่เคยทำมาก่อนได้อีกต่อไป Tapestry 5 ดูเหมือนจะมีการปรับปรุงที่สำคัญ แต่ปัญหาหลักของฉันกับ Tapestry ไม่ได้เกิดจากตัวแพลตฟอร์ม มันอยู่กับคนที่อยู่เบื้องหลัง

ในอดีตการอัปเดต Tapestry เวอร์ชันหลักทุกครั้งได้ทำลายความเข้ากันได้แบบย้อนหลังด้วยอคติที่รุนแรงเกินกว่าที่ใครจะคาดคิด สิ่งนี้น่าจะเกิดจากการรวมเทคนิคการเข้ารหัสหรือเทคโนโลยีใหม่ ๆ ที่ต้องการการเขียนซ้ำที่สำคัญ

Howard Lewis Ship (ผู้เขียนหลักของ Tapestry) เป็นนักพัฒนาที่ยอดเยี่ยม แต่ฉันไม่สามารถพูดได้ว่าฉันดูแลการจัดการโครงการ Tapestry ของเขา การพัฒนา Tapestry 5 เริ่มขึ้นเกือบจะในทันทีหลังจากส่ง Tapestry 4 จากสิ่งที่ฉันบอกได้ Ship ค่อนข้างทุ่มเทให้กับสิ่งนั้นโดยปล่อยให้ Tapestry 4 อยู่ในมือของผู้ร่วมให้ข้อมูลคนอื่น ๆ ซึ่งฉันรู้สึกว่ามีความสามารถไม่เท่า Ship หลังจากเปลี่ยนความเจ็บปวดจาก Tapestry 3 เป็น Tapestry 4 แล้วฉันรู้สึกว่าตัวเองถูกทอดทิ้งแทบจะในทันที

แน่นอนด้วยการเปิดตัว Tapestry 5 ทำให้ Tapestry 4 กลายเป็นผลิตภัณฑ์ดั้งเดิม ฉันจะไม่มีปัญหากับเรื่องนี้ถ้าเส้นทางการอัพเกรดไม่โหดอีกแล้ว ตอนนี้ทีมพัฒนาของเราอยู่ในตำแหน่งที่ค่อนข้างไม่มีใครยอมรับได้: เราสามารถใช้แพลตฟอร์มเว็บที่ถูกทิ้งร้างไป (Tapestry 4) ต่อไปทำการอัปเกรดเป็น Tapestry 5 หรือยอมแพ้ Tapestry ทั้งหมดและเขียนแอปพลิเคชันของเราใหม่โดยใช้แพลตฟอร์มอื่น ไม่มีตัวเลือกใดที่น่าสนใจมาก

Tapestry 5 ถูกเขียนขึ้นเพื่อลดความเป็นไปได้ที่การอัปเดตจะแตกจากจุดนี้ไปข้างหน้า ตัวอย่างที่ดีคือในคลาสเพจ: ในชาติก่อนหน้าคลาสที่สืบเชื้อสายมาจากคลาสพื้นฐานที่จัดทำโดย Tapestry; การเปลี่ยนแปลง API ที่เข้ากันไม่ได้ในคลาสนี้เป็นสาเหตุของปัญหาความเข้ากันได้ย้อนหลังจำนวนมาก ใน Tapestry 5 หน้าคือ POJO ซึ่งได้รับการปรับปรุงในขณะรันไทม์ด้วย "magic Tapestry fairy dust" ผ่านคำอธิบายประกอบ ตราบเท่าที่ยังคงรักษาสัญญาสำหรับคำอธิบายประกอบไว้การเปลี่ยนแปลง Tapestry จะไม่ส่งผลกระทบต่อคลาสเพจของคุณ

หากถูกต้องการเขียนแอปพลิเคชันใหม่โดยใช้ Tapestry 5 อาจทำได้ดี แต่โดยส่วนตัวแล้วฉันไม่รู้สึกอยากวางมือบนเตาอีกเลย

Disclamer: ฉันทำงานที่ Vaadin (เดิมคือ IT Mill)

ถ้าคุณกำลังทำบางสิ่งบางอย่าง RIAish คุณอาจต้องการที่จะดูที่Vaadin มันเป็นเฟรมเวิร์ก AJAX ที่เน้น UI แบบโอเพนซอร์สซึ่งสำหรับฉันแล้วน่าใช้ (ฉันมาจากพื้นหลัง PHP เอง)

มีกรณีศึกษาที่เปรียบเทียบการทำแอปพลิเคชันเดียวกัน (เช่นสองแอปพลิเคชันที่มีคุณสมบัติชุดเดียวกัน) ใน Icefaces และ Vaadin สรุปได้ว่าการพัฒนา UI นั้นเร็วกว่ามาก

แม้ว่าการศึกษาจะจัดขึ้นที่ wiki ของ บริษัท แต่ฉันสามารถมั่นใจได้ว่าวัตถุประสงค์เป็นของจริงและเป็นความจริงแม้ว่าฉันจะไม่สามารถบังคับให้คุณเชื่อฉันได้

หลังจากทดสอบวิธีแก้ปัญหาต่างๆมานานแล้วสำหรับฉันมันกลายเป็น:

• Spring MVC สำหรับเลเยอร์การนำเสนอและคอนโทรลเลอร์ (ไม่มี Spring Webflow เนื่องจากโฟลว์ของฉันขึ้นอยู่กับ ajax)

• jQuery สำหรับเนื้อหาฝั่งไคลเอ็นต์ทั้งหมด

• Spring Security สำหรับด้านความปลอดภัย

• ไฮเบอร์เนต / JPA2

• ท่าเทียบเรือเพื่อความต่อเนื่อง (ดาวหาง)

หนึ่งเดือนของช่วงการเรียนรู้ที่สูงชันเป็นพิเศษ แต่ตอนนี้ฉันมีความสุข

ฉันอยากจะพูดถึงว่าฉันอยู่ห่างจากการข้ามเนื้อหา Java ทั้งหมดและใช้ Scala / LIFT แทน เท่าที่ฉันกังวลทุกอย่างใน Java ที่เกี่ยวข้องกับการพัฒนาเว็บที่ทันสมัย ​​(ดาวหาง, การสื่อสารแบบ async, การรักษาความปลอดภัย (ใช่แม้กระทั่งกับ Spring Security!)) ยังคงเป็นการแฮ็กเล็กน้อย (พิสูจน์ว่าฉันผิดด้วยหลักฐานขอร้อง !). สำหรับฉันแล้ว Scala / LIFT ดูเหมือนจะเป็นวิธีแก้ปัญหาแบบเบ็ดเสร็จและครบวงจรมากกว่า

เหตุผลที่ในที่สุดฉันตัดสินใจไม่ไปกับสกาลาคือ

• ในฐานะหัวหน้าโครงการฉันต้องพิจารณาว่าทรัพยากรบุคคลและนักพัฒนา Java หาได้ง่ายกว่านักพัฒนา Scala มาก

• สำหรับนักพัฒนาส่วนใหญ่ในทีมของฉันแนวคิด funcional ของ Scala นั้นยอดเยี่ยมอย่างที่เป็นอยู่นั้นยากที่จะเข้าใจ

ไชโยเอ้อ

ฉันเคยได้ยินสิ่งดีๆเกี่ยวกับ Spring Framework ด้วย โดยทั่วไปแล้วฉันรู้สึกผิดหวังกับเว็บเฟรมเวิร์กส่วนใหญ่ที่ฉันเคยดู (esp Struts)

สำหรับแอปที่เรียบง่ายฉันควรพิจารณาใช้ servlets และ JSP แบบ "raw" และไม่ต้องกังวลกับการใช้กรอบงาน หาก servlets เขียนได้ดีในอนาคตควรจะพอร์ตไปยังเฟรมเวิร์กอย่างตรงไปตรงมาหากจำเป็นเมื่อแอปมีความซับซ้อนมากขึ้น

สิ่งที่ฉันเลือกคือประตู !!

ทั้งหมด - นั่นคือปัญหา ;-)

ฉันคิดว่าสำหรับความต้องการที่เรียบง่ายของคุณคุณเพียงแค่ต้องเขียนโค้ด servlets หรือหน้า jsp ง่ายๆที่คุณสามารถให้บริการจากเซิร์ฟเวอร์ Tomcat ฉันไม่คิดว่าคุณต้องการ web-framework (เช่น struts) สำหรับข้อมูลเว็บไซต์ส่วนตัว

การพูดว่า "ใช้ JSF" นั้นง่ายไปหน่อย เมื่อคุณตัดสินใจใช้ JSF คุณต้องเลือกไลบรารีคอมโพเนนต์ที่ด้านบน คุณจะใช้ MyFaces Tomahawk, Trinidad, Tobago ( http://myfaces.apache.org/ ) หรือไม่ หรืออาจจะเป็น ICEfaces ( http://www.icefaces.org/ )? อ้อถ้าคุณใช้ ICEfaces คุณจะใช้ JSPs หรือ Facelets ในการดูของคุณหรือไม่?

ในความคิดของฉันมันยากที่จะบอก ไม่มีใครมีเวลาประเมินทางเลือกที่มีแนวโน้มทั้งหมดอย่างน้อยก็ในโครงการที่ฉันทำอยู่เพราะพวกเขาไม่ใหญ่พอที่จะทำการประเมินระยะสามเดือน อย่างไรก็ตามคุณควรมองหาบางส่วนที่มีชุมชนใหญ่และกระตือรือร้นและไม่ได้หายไปในหนึ่งปี JSF อยู่ในช่วงเวลาหนึ่งและเนื่องจากได้รับแรงผลักจากดวงอาทิตย์จึงจะกลับมาอีก ฉันไม่สามารถพูดได้ว่ามันเป็นทางเลือกที่ดีที่สุด แต่มันจะเป็นทางเลือกที่ดี

http://zkoss.org - สิ่งที่ดี

สำหรับไซต์ที่มีการเข้าชมสูงฉันจะใช้เฟรมเวิร์กที่ไม่ได้จัดการสถานะไคลเอ็นต์บนเซิร์ฟเวอร์ - Wicket, JSF และ Tapestry กำลังจัดการสถานะไคลเอ็นต์บนเซิร์ฟเวอร์ ฉันจะใช้เฟรมเวิร์กเหล่านั้นเท่านั้น (Wicket เป็นรายการโปรดของฉัน) หากแอปพลิเคชันควรเป็นแอปพลิเคชันบนเดสก์ท็อปมากกว่า แต่ฉันจะพยายามใช้วิธี REST + AJAX ที่ปรับขนาดได้และเรียบง่ายกว่านี้

Spring MVC จะเป็นตัวเลือก แต่เนื่องจาก Spring MVC 3 มีรูปแบบการเขียนโปรแกรมที่มีคำอธิบายประกอบมากเกินไปซึ่งไม่ได้ใช้ประโยชน์จากการพิมพ์แบบคงที่ มีสิ่งที่น่าเกลียดอื่น ๆ เช่นพารามิเตอร์เอาต์พุตในวิธีการรวมกับการส่งคืนปกติดังนั้นจึงมีช่องสัญญาณเอาต์พุตสองช่องในหนึ่งวิธี Spring MVC ยังมีแนวโน้มที่จะสร้างวงล้อใหม่และคุณจะต้องกำหนดค่ามากกว่าเมื่อเทียบกับเฟรมเวิร์กอื่น ๆ ฉันไม่สามารถแนะนำ Spring MVC ได้แม้ว่าจะมีความคิดที่ดี

Grails เป็นวิธีที่สะดวกในการใช้ Spring MVC และเฟรมเวิร์กอื่น ๆ เช่น Hibernate การเขียนโค้ดเป็นเรื่องสนุกและคุณจะเห็นผลลัพธ์อย่างรวดเร็ว

และอย่าลืมว่า Servlet API ที่มีตัวช่วยเล็ก ๆ น้อย ๆ เช่น FreeMarker สำหรับเทมเพลตนั้นมีประสิทธิภาพมาก

ฉันได้ประเมินเฟรมเวิร์กไปแล้วค่อนข้างน้อยและ Vaadin ( http://vaadin.com/home ) ได้เจาะลึกไปที่ด้านบนสุด

อย่างน้อยคุณควรประเมินสั้น ๆ

ไชโย!

สิ่งที่ฉันเลือกคือ Wicket (สำหรับโครงการขนาดใหญ่และฐานผู้ใช้ที่คาดเดาได้), GWT (สำหรับโครงการขนาดใหญ่ที่ส่วนใหญ่เป็นสาธารณะ) หรือเพียงแค่กรอบการบริการ (เช่น Jersey / JAXRS) ร่วมกับชุดเครื่องมือ JavaScript (สำหรับโครงการขนาดเล็กถึงขนาดกลาง) .

ฉันแนะนำ Seam โดยเฉพาะอย่างยิ่งถ้าคุณต้องการความคงอยู่

ดูความคิดเห็นเล็กน้อยเกี่ยวกับ Java application Frameworks (ย่อหน้าที่สอง):

http://swiss-knife.blogspot.com/2009/11/some-java-application-servers.html

สำหรับGUI ที่รวดเร็วและสวยงามคุณสามารถใช้ JSF กับไลบรารีRichfaces ส่วนประกอบ Richfaces UI นั้นใช้งานง่ายและมีการอ้างอิงที่สะดวกพร้อมการสาธิตโค้ดในไซต์สาธิต ในภายหลังเมื่อไซต์ของคุณมีข้อมูลที่ต้องจัดการมากขึ้นและต้องมีการทำธุรกรรมข้อมูลจำนวนมากในฐานข้อมูลคุณสามารถเสียบกรอบการเข้าถึงฐานข้อมูล (ORM) ใดก็ได้

ไม่อยากจะเชื่อเลยว่าไม่มีใครพูดถึง GWT

วิธีที่ฉันชอบที่สุดในการใช้แอพง่ายๆคือ Apache VelocityTools (VelocityLayoutServlet) กับ Velosurf ( http://velosurf.sourceforge.net )

สำหรับแอปที่ซับซ้อนมากขึ้น Spring MVC หรือ Struts 2

ลอง HybridJava ซึ่งง่ายกว่าอย่างอื่น

ฉันจะบอกว่าvaadinหรือwicket