เหตุผลที่จะไม่ใช้ JSF [ปิด]

64

ฉันใหม่กับ StackExchange แต่ฉันคิดว่าคุณจะสามารถช่วยฉันได้

เรากำลังสร้างแอปพลิเคชัน Java Enterprise ใหม่แทนที่โซลูชัน JSP ดั้งเดิม เนื่องจากมีการเปลี่ยนแปลงมากมาย UI และส่วนต่างๆของตรรกะทางธุรกิจจะได้รับการพิจารณาและนำมาใช้ใหม่อย่างสมบูรณ์

ความคิดแรกของเราคือ JSF เนื่องจากเป็นมาตรฐานใน Java EE ตอนแรกฉันมีความประทับใจที่ดี แต่ตอนนี้ฉันกำลังพยายามใช้ต้นแบบการทำงานและมีข้อกังวลอย่างจริงจังเกี่ยวกับการใช้งาน

ก่อนอื่นมันสร้างการผสมผสานที่ไม่ถูกต้องที่เลวร้ายที่สุดและยุ่งเหยิงที่สุดที่ไม่เคยมีมาก่อนซึ่งฉันไม่เคยเห็นมาก่อน มันละเมิดกฎทุกข้อที่ฉันได้เรียนรู้ในการพัฒนาเว็บ นอกจากนี้มันจะรวมเข้าด้วยกันสิ่งที่ไม่ควรเชื่อมโยงกันอย่างแน่นหนา: เค้าโครงการออกแบบลอจิกและการสื่อสารกับเซิร์ฟเวอร์ ฉันไม่เห็นวิธีที่ฉันจะสามารถขยายผลลัพธ์นี้ได้อย่างสะดวกสบายไม่ว่าจะเป็นการจัดแต่งทรงผมด้วย CSS, การเพิ่มลูกกวาด UI (เช่นปุ่มลัดที่สามารถกำหนดค่าได้, วิดเจ็ตลากและวาง) หรืออะไรก็ตาม

ประการที่สองมันซับซ้อนเกินไป ความซับซ้อนของมันโดดเด่น หากคุณถามฉันมันเป็นนามธรรมที่ไม่ดีของเทคโนโลยีเว็บพื้นฐานพิการและไร้ประโยชน์ในที่สุด ฉันมีประโยชน์อะไรบ้าง ไม่มีถ้าคุณคิด ส่วนประกอบหลายร้อย ฉันเห็นตัวอย่างโค้ด HTML / CSS หมื่นตัวอย่างโค้ด JavaScript นับหมื่นและปลั๊กอิน jQuery นับพัน มันแก้ปัญหาได้มากมาย - เราจะไม่มีถ้าเราไม่ใช้ JSF หรือรูปแบบตัวควบคุมด้านหน้าเลย

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

ข้อเสนอแนะของฉันคือการใช้ REST api โดยใช้ JAX-RS จากนั้นสร้างไคลเอนต์ HTML5 / Javascript ด้วย MVC ฝั่งไคลเอ็นต์ (หรือรสชาติของ MVC .. ) โดยวิธีการ; เราจะต้องใช้ REST api ต่อไปเนื่องจากเรากำลังพัฒนา Android front-end บางส่วนเช่นกัน

ฉันสงสัยว่า JSF เป็นทางออกที่ดีที่สุดในปัจจุบัน ขณะที่อินเทอร์เน็ตกำลังพัฒนาฉันไม่เห็นว่าทำไมเราจึงควรใช้ 'rake' นี้

ตอนนี้ข้อดี / ข้อเสียคืออะไร? ฉันจะเน้นจุดของฉันที่จะไม่ใช้ JSF ได้อย่างไร อะไรคือจุดแข็งที่จะใช้ JSF เหนือข้อเสนอแนะของฉัน

— บรูโนSchäpper
แหล่งที่มา

24

นั่นเป็นคำถามที่เขียนมาอย่างดีจากผู้ใช้รายใหม่ พิจารณาออกความคิดเห็นเมื่อ downvoting

— ThiefMaster

2

เนื่องจากคุณเขียนใหม่ทุกอย่างฉันจึงไม่เพียง แต่พิจารณาใช้ JSF แต่ไม่พิจารณาใช้ Java เลย ภาษาสคริปต์สมัยใหม่ (เช่นไม่ใช่ PHP หรือ Perl) ค่อนข้างดีและเป็นมิตรกับผู้พัฒนา

— ThiefMaster

11

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

— Michael Borgwardt

4

Java เป็นตัวเลือกที่ดีที่สุดหากแอปพลิเคชันของคุณมีขนาดใหญ่ (ซับซ้อนและ / หรือปรับขนาดได้) และ / หรือกระจายโดยใช้บริการมากมาย หากใบสมัครของคุณไม่เหมาะกับหมวดหมู่นี้ (ไม่ซับซ้อนและไม่จำเป็นต้องปรับขนาดได้) Python (Django) หรือ Ruby (Rails) จะเป็นตัวเลือกที่ดีกว่า ความซับซ้อนของ JSF มีประโยชน์ของพลังงานที่มาพร้อมกับ คุณควรพิจารณา Web Frameworks อื่น ๆ เช่น Spring MVC หรือ Struts 2 หาก Java จำเป็นต้องมี

— m3th0dman

14

นี่เป็นการคุยโวที่กำลังมองหาการสำรองข้อมูลไม่ใช่คำถามเช่นนี้

26

มีเหตุผลที่ดีอย่างน้อยหนึ่งข้อในการพิจารณา JSF

เป็นส่วนมาตรฐานของสแต็ก Java EE และจะพร้อมใช้งานและทำงานในคอนเทนเนอร์ Java EE ทั้งหมดเป็นเวลานานมาก และดูแลรักษาด้วยเช่นกันโดยที่คุณไม่ต้องทำเช่นนั้นหากคุณปฏิบัติตามข้อกำหนด Java EE อย่างเคร่งครัด

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

4

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

— magallanes

7

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

— Jens Schauder

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

— ymajoros

14

ตอนนี้ข้อดี / ข้อเสียคืออะไร? ฉันจะเน้นจุดของฉันที่จะไม่ใช้ JSF ได้อย่างไร อะไรคือจุดแข็งที่จะใช้ JSF เหนือข้อเสนอแนะของฉัน

คุณดูเหมือนจะทำให้ใจของคุณเกี่ยวกับข้อเสียและฉันต้อง gree กับบางคน (มันไม่แยกเค้าโครงและตรรกะพอและ HTML ที่เกิดขึ้นมักจะเลวร้าย) แต่ไม่เห็นด้วยกับคนอื่น ๆ (ถ้าคุณใช้ Facelets ซึ่งฉันอยากจะแนะนำอย่างมากจากนั้นผลลัพธ์ที่ได้ควรมีผลอย่างแน่นอน)

ดังนั้นนี่คือข้อดี:

มีไลบรารีองค์ประกอบที่ทรงพลังบางอย่างเช่น PrimceFaces หรือ RichFaces ที่มีฟังก์ชั่นการใช้งานมากมาย สิ่งเหล่านี้สามารถประหยัดงานได้มากหากพวกเขาครอบคลุมความต้องการของคุณ (ไม่มากถ้าคุณมีข้อกำหนดที่ไม่สามารถเจรจาต่อรองไม่ได้ครอบคลุมโดยพวกเขา)
คอมโพสิตส่วนประกอบเป็นวิธีที่สะอาดมากในการทำให้หน้าของคุณเป็นโมดูล
JSF รวมเข้ากับ Java EE ที่เหลือได้เป็นอย่างดี
AJAX ผ่านการเรนเดอร์องค์ประกอบใหม่นั้นง่ายและสะดวกมาก

แต่แน่นอนว่าไม่มีข้อได้เปรียบเหล่านี้มีขนาดใหญ่จนคุณควรใช้ JSF บนกรอบงานอื่น ๆ ที่ทีมของคุณมีประสบการณ์อยู่แล้ว

— Michael Borgwardt
แหล่งที่มา

1

ไม่ใช่รหัส แต่เป็นแอตทริบิวต์ที่ไม่ถูกต้อง กดไลค์ "role" และ "aria-expanded" ในมุมมองแท็บ คุณรู้วิธีแก้ไขปัญหานี้หรือไม่?

— Bruno Schäpper

1

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

— Michael Borgwardt

1

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

1

@ Thorbjørn Ravn Andersen ใช่ปัญหาของ HTML ที่ไม่ถูกต้องเป็นปัญหาของ PrimeFaces เราใช้มันเพราะมันสร้างบน jQuery-UI คำแนะนำของคุณคืออะไร ฉันควรใช้ห้องสมุดอื่น ฉันชอบ HTML ที่ถูกต้อง สำหรับฉันมันเป็นแค่ต้อง

— Bruno Schäpper

1

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

— Bruno Schäpper

9

JSF เป็นเฟรมเวิร์กเว็บที่มีสถานะเพียงพอสำหรับ Java ซึ่งเป็นมาตรฐานซึ่งหมายความว่าได้รับการสนับสนุนจากผู้จำหน่ายรายใหญ่หลายราย (รวมถึง FOSS) มันมีการสนับสนุนห้องสมุดบุคคลที่สามที่แข็งแกร่ง (PrimeFaces, IceFaces ฯลฯ ) อย่างไรก็ตามโดยพื้นฐานแล้วมันจะ 'ทำลายเว็บ' เนื่องจากลักษณะที่เป็นรัฐ (และสิ่งอื่น ๆ ) ดูการเปรียบเทียบของเฟรมเวิร์กบนเว็บที่อิง JVM ของ Matt Raibleโดยปกติแล้ว JSF จะเข้าใกล้ล่าสุด

แก้ไข - ด้วย JSF 2.2 - คุณสามารถเริ่มเถียงว่าจะไม่ทำให้เว็บแตกเท่าที่เคยทำ อันที่จริงแล้วการบูรณาการ HTML5 นั้นไม่ใช่ :-) ที่น่ากลัว

— Martijn Verburg
แหล่งที่มา

1

มัน 'ทำลายเว็บ' แน่นอน .. และขอบคุณสำหรับการเปรียบเทียบของ Matt Raible ไม่รู้ว่า

— Bruno Schäpper

3

โปรดทราบว่า JSF ไม่จำเป็นต้องระบุสภาวะ ฉันเห็นด้วยบ่อยครั้ง แต่มีการสนับสนุนที่ดีมากสำหรับการร้องขอแบบไร้ GET และถ้าคุณไม่ใช้แบบฟอร์มแสดงว่าไม่มีรัฐเลย

— Arjan Tijms

พอใช้ Arjan ฉันเดาว่าฉันเคยเห็นการใช้งานที่เป็นรัฐหลายอย่าง

— Martijn Verburg

ลิงก์ไปยังงานนำเสนอของ Raible: slideshare.net/mraible/…

— zaidaus

6

เรามีแอปพลิเคชั่น JSP / Struts 1.0 ที่เป็นมรดก เราข้าม Struts 2, JSF และทุกอย่างอื่นที่เกิดขึ้นตั้งแต่ Struts 1 และกระโดดไปที่ Spring 3.0 มันมีการสนับสนุน (และชุมชนที่ใช้งาน) สำหรับรายการความปรารถนาของเรา - Eclipse IDE, MVC และ REST นอกจากนี้เรายังใช้ Javascript / ajax สำหรับผลิตเหล้าองุ่นของเรา

YMMV แต่ฤดูใบไม้ผลิเป็นการย้ายที่ราบรื่นสำหรับเรา

— JQA
แหล่งที่มา