อะไรคือข้อเสียเปรียบหลักของ Java Server Faces 2.0?

เมื่อวานนี้ฉันเห็นงานนำเสนอบน Java Server Faces 2.0 ซึ่งดูน่าประทับใจอย่างแท้จริงแม้ว่าฉันจะเป็นนักพัฒนา ASP.NET MVC / jQuery ที่มีความสุข สิ่งที่ฉันชอบมากที่สุดเกี่ยวกับ JSF คือส่วนประกอบ AJAX-Enabled UI ซึ่งดูเหมือนจะทำให้การพัฒนาเร็วกว่า ASP.NET MVC โดยเฉพาะอย่างยิ่งบนไซต์ AJAX ที่ใช้งานหนัก การทดสอบบูรณาการดูดีมากเช่นกัน

เนื่องจากงานนำเสนอเน้นเฉพาะข้อดีของ JSF ฉันจึงอยากได้ยินเกี่ยวกับอีกด้านหนึ่งเช่นกัน

ดังนั้นคำถามของฉันคือ:

• อะไรคือข้อเสียเปรียบหลักของ Java Server Faces 2.0?
• อะไรที่ทำให้นักพัฒนา JSF พิจารณาใช้ ASP.NET MVC แทน JSF

ข้อเสีย JSF 2.0? จริงๆแล้วนอกเหนือจากการเรียนรู้ที่สูงชันเมื่อคุณไม่มีความรู้พื้นฐานเกี่ยวกับการพัฒนาเว็บขั้นพื้นฐาน (HTML / CSS / JS, ฝั่งเซิร์ฟเวอร์กับฝั่งไคลเอ็นต์, ฯลฯ ) และJava Servlet API ขั้นพื้นฐาน (คำขอ / ตอบกลับ / เซสชัน การส่งต่อ / การเปลี่ยนเส้นทาง ฯลฯ ) ไม่มีข้อเสียที่ร้ายแรงอยู่ในใจ JSF ในรีลีสปัจจุบันยังคงต้องการกำจัดภาพลบที่ได้รับในช่วงวัยเด็กซึ่งมีข้อเสียร้ายแรงหลายประการ

JSF 1.0 (มีนาคม 2004)

นี่คือการเปิดตัวครั้งแรก มันเต็มไปด้วยข้อบกพร่องทั้งในส่วนหลักและส่วนประสิทธิภาพที่คุณไม่ต้องการรู้ แอปพลิเคชันของคุณไม่ได้ผลเสมอไป คุณในฐานะนักพัฒนาจะร้องไห้อย่างหนัก

JSF 1.1 (พฤษภาคม 2004)

นี่เป็นรุ่นแก้ไขข้อผิดพลาด ประสิทธิภาพยังไม่ดีขึ้นมาก มีข้อเสียอย่างหนึ่งที่สำคัญคือคุณไม่สามารถอินไลน์ HTML ในหน้า JSF ได้อย่างไม่มีที่ติ vanilla HTML ล้วนรับการเรนเดอร์ก่อนโครงสร้างส่วนประกอบ JSF คุณจำเป็นต้องห่อวานิลลาธรรมดาทั้งหมดใน<f:verbatim>แท็กเพื่อให้มันถูกรวมไว้ในโครงสร้างองค์ประกอบ JSF แม้ว่านี่จะเป็นไปตามข้อกำหนด แต่ก็ได้รับการวิจารณ์จำนวนมาก ดูเพิ่มเติม ao JSF / Facelets: เหตุใดจึงไม่ควรผสม JSF / Facelets กับแท็ก HTML

JSF 1.2 (พฤษภาคม 2549)

นี่เป็นรุ่นแรกของทีมพัฒนา JSF ใหม่ที่นำโดย Ryan Lubke ทีมใหม่ทำงานได้ดีเยี่ยมมาก นอกจากนี้ยังมีการเปลี่ยนแปลงในสเป็ค การเปลี่ยนแปลงที่สำคัญคือการปรับปรุงการจัดการมุมมอง สิ่งนี้ไม่เพียง แต่แยกออกอย่างสมบูรณ์จาก JSP JSP ดังนั้นหนึ่งสามารถใช้เทคโนโลยีมุมมองที่แตกต่างจาก JSP แต่มันยังอนุญาตให้นักพัฒนาสามารถ inline ธรรมดาวานิลลา HTML ในหน้า JSF โดยไม่ต้องยุ่งกับ<f:verbatim>แท็ก จุดสนใจที่สำคัญอีกประการหนึ่งของทีมใหม่คือการปรับปรุงประสิทธิภาพ ในช่วงอายุการใช้งานของ Sun JSF Reference Implementation 1.2 (ซึ่งมีชื่อรหัสว่าMojarraตั้งแต่สร้าง 1.2_08 ประมาณปี 2008) ในทางปฏิบัติทุกบิลด์ได้ส่งมอบพร้อมกับการปรับปรุงประสิทธิภาพ (หลัก) ถัดจากข้อผิดพลาดปกติ (เล็กน้อย)

ข้อเสียที่ร้ายแรงเพียงหนึ่งเดียวของ 1.x JSF (รวม 1.2) คือการขาดการขอบเขตในระหว่างการร้องขอและเซสชั่นขอบเขตที่เรียกว่าการสนทนาขอบเขต นักพัฒนานี้ถูกบังคับให้ยุ่งยากกับองค์ประกอบการป้อนข้อมูลที่ซ่อนอยู่, แบบสอบถามฐานข้อมูลที่ไม่จำเป็นและ / หรือใช้ขอบเขตเซสชันเมื่อใดก็ตามที่ผู้ใช้ต้องการเก็บข้อมูลโมเดลเริ่มต้นในคำขอถัดไปเพื่อที่จะประมวลผลการตรวจสอบความถูกต้อง แอปพลิเคชันที่ซับซ้อน ความเจ็บปวดอาจลดลงได้โดยการใช้ห้องสมุดบุคคลที่ 3 ซึ่งเก็บข้อมูลที่จำเป็นไว้ในคำขอต่อไปเช่นMyFaces Tomahawk <t:saveState> component, ขอบเขตการสนทนาJBoss SeamและMyFaces Orchestra กรอบการสนทนา

ข้อเสียเปรียบอีกประการสำหรับการใช้ HTML / CSS คือ JSF ใช้โคลอน:เป็นตัวคั่น ID เพื่อให้แน่ใจว่าองค์ประกอบ HTML idในเอาท์พุต HTML ที่สร้างขึ้นไม่ซ้ำกันโดยเฉพาะอย่างยิ่งเมื่อส่วนประกอบถูกนำมาใช้ซ้ำมากกว่าหนึ่งครั้งในมุมมอง (เทมเพลต . เพราะนี่เป็นตัวละครที่ผิดกฎหมายในตัวระบุ CSS คุณจะต้องใช้\ในการหลบหนีลำไส้ใหญ่ในตัวเลือก CSS ที่มีผลในตัวเลือกที่น่าเกลียดและแปลกมองเช่นหรือแม้กระทั่ง#formId\:fieldId {} #formId\3A fieldId {}ดูเพิ่มเติมวิธีใช้ JSF สร้างรหัสองค์ประกอบ HTML กับโคลอน ":" ในตัวเลือก CSS ได้อย่างไร แต่ถ้าคุณไม่ได้เป็นคนเจ้าระเบียบอ่านยังโดยค่าเริ่มต้น JSF สร้างรหัสที่ใช้ไม่ได้ซึ่งจะเข้ากันกับส่วนหนึ่งของ CSS มาตรฐานเว็บ

นอกจากนี้ JSF 1.x ไม่ได้จัดส่งสิ่งอำนวยความสะดวก Ajax ออกจากกล่อง ไม่ใช่ข้อเสียทางเทคนิคจริงๆ แต่เนื่องจาก Web 2.0 hype ในช่วงเวลานั้นมันกลายเป็นข้อเสียการทำงาน Exadelได้เปิดตัว Ajax4jsf ซึ่งได้รับการพัฒนาอย่างละเอียดในช่วงหลายปีที่ผ่านมาและกลายเป็นส่วนสำคัญของไลบรารีคอมโพเนนต์JBoss RichFaces อีกห้องสมุดองค์ประกอบที่ถูกส่งไปด้วยในตัวพลังอาแจ็กซ์เป็นอย่างดีที่รู้จักกันดีหนึ่งเป็นICEfaces

ประมาณครึ่งอายุการใช้งาน JSF 1.2 ซึ่งเป็นเทคโนโลยี XML มุมมองใหม่บนพื้นฐานได้รับการแนะนำ: Facelets สิ่งนี้นำเสนอข้อได้เปรียบอย่างมหาศาลเหนือ JSP โดยเฉพาะในพื้นที่ของการสร้างเทมพ

JSF 2.0 (มิถุนายน 2552)

นี่เป็นรุ่นใหญ่ครั้งที่สองโดยมี Ajax เป็น buzzword มีการเปลี่ยนแปลงทางเทคนิคและฟังก์ชั่นมากมาย JSP ถูกแทนที่ด้วย Facelets เนื่องจากเทคโนโลยีมุมมองเริ่มต้นและ Facelets ถูกขยายด้วยความสามารถในการสร้างส่วนประกอบที่กำหนดเองโดยใช้ XML บริสุทธิ์ ( คอมโพเนนต์คอมโพสิตที่เรียกว่า) ดูเพิ่มเติมเพราะเหตุใดจึงเลือก Facelets มากกว่า JSP เนื่องจากภาษาการนิยามมุมมองจาก JSF2.0 เป็นต้นไป

อาแจ็กซ์พาวเวอร์ได้รับการแนะนำในรสชาติของ<f:ajax>ส่วนประกอบที่มีความคล้ายคลึงกันมากกับ Ajax4jsf คำอธิบายประกอบและการปรับปรุงการกำหนดค่าแบบแผนได้ถูกนำเสนอเพื่อฆ่าfaces-config.xmlไฟล์verbose ให้มากที่สุด นอกจากนี้อักขระการตั้งชื่อเริ่มต้นของตัวคั่น ID คอนเทนเนอร์:ก็สามารถกำหนดค่าได้ดังนั้นผู้ที่จะใช้ HTML / CSS ก็สามารถผ่อนคลายได้ ทั้งหมดที่คุณต้องทำคือการกำหนดเป็นinit-paramในweb.xmlที่มีชื่อjavax.faces.SEPARATOR_CHARและมั่นใจว่าคุณไม่ได้ใช้ตัวอักษรตัวเองได้ทุกที่ใน ID -ของลูกค้าเช่น

สุดท้าย แต่ไม่น้อยขอบเขตใหม่ได้รับการแนะนำที่มุมมองขอบเขต มันกำจัดข้อเสียที่สำคัญอีกข้อหนึ่งของ JSF 1.x ตามที่อธิบายไว้ก่อนหน้านี้ คุณเพิ่งประกาศ bean @ViewScopedเพื่อเปิดใช้งานขอบเขตการสนทนาโดยไม่ต้องยุ่งยากในการเก็บข้อมูลในการร้องขอ (การสนทนา) ที่ตามมา @ViewScopedถั่วจะมีชีวิตอยู่ได้นานเท่าที่คุณส่งต่อมาและการนำไปยังมุมมองเดียวกัน (เป็นอิสระจากเบราว์เซอร์เปิดแท็บ / หน้าต่าง!) อย่างใดอย่างหนึ่งพร้อมหรือไม่พร้อม (อาแจ็กซ์) ดูเพิ่มเติมความแตกต่างระหว่างขอบเขตการดูและคำขอในถั่วที่ได้รับการจัดการและวิธีการเลือกขอบเขตถั่วที่ถูกต้อง?

แม้ว่าในทางปฏิบัติแล้วข้อเสียทั้งหมดของ JSF 1.x ถูกกำจัดไปแล้ว แต่มีข้อบกพร่องเฉพาะของ JSF 2.0 ซึ่งอาจกลายเป็น showstopper ความ@ViewScopedล้มเหลวในตัวจัดการแท็กเนื่องจากปัญหาไก่ไข่ในการบันทึกสถานะบางส่วน สิ่งนี้ได้รับการแก้ไขใน JSF 2.2 และย้อนกลับใน Mojarra 2.1.18 นอกจากนี้ยังไม่สนับสนุนแอตทริบิวต์ที่กำหนดเองเช่น HTML5data-xxxด้วย สิ่งนี้ได้รับการแก้ไขใน JSF 2.2 โดยคุณลักษณะ passthrough ใหม่ / คุณสมบัติ ส่งเสริมการใช้ JSF กระโดงมีชุดของตัวเองของปัญหา ค่อนข้างมากของพวกเขาที่เกี่ยวข้องกับพฤติกรรมบางครั้ง unintuitive ของ<ui:repeat>การดำเนินการประหยัดรัฐใหม่บางส่วนและขอบเขตการดำเนินการต่ำแฟลช ส่วนใหญ่ได้รับการแก้ไขในเวอร์ชั่น Mojarra 2.2.x

ในช่วงเวลาของ JSF 2.0 นั้นPrimeFacesได้รับการแนะนำโดยใช้ jQuery และ jQuery UI มันกลายเป็นไลบรารีคอมโพเนนต์ JSF ที่นิยมมากที่สุด

JSF 2.2 (พฤษภาคม 2013)

ด้วยการแนะนำ JSF 2.2 ทำให้ HTML5 ถูกใช้เป็น buzzword แม้ว่าจะได้รับการสนับสนุนทางเทคนิคในรุ่น JSF รุ่นเก่าทั้งหมดเท่านั้น ดูเพิ่มเติมJavaServer Faces 2.2 และการสนับสนุน HTML5, XHTML ทำไมยังคงถูกใช้ ที่สำคัญ JSF 2.2 คุณลักษณะใหม่มากที่สุดคือการสนับสนุนสำหรับคุณลักษณะองค์ประกอบที่กำหนดเองขอเปิดโลกของความเป็นไปได้เช่นกลุ่มปุ่ม tableless ที่กำหนดเอง

นอกเหนือจากการใช้งานข้อผิดพลาดเฉพาะและ "สิ่งเล็ก ๆ น้อย ๆ ที่น่ารำคาญ" เช่นการไม่สามารถฉีด EJB ใน validator / converter (แก้ไขแล้วใน JSF 2.3) ไม่มีข้อเสียที่สำคัญในข้อกำหนด JSF 2.2

MVC ตามส่วนประกอบเทียบกับ MVC ตามคำขอ

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

ดูสิ่งนี้ด้วย:

• ความแตกต่างระหว่าง JSF, Servlet และ JSP คืออะไร? (เพียงเข้าใจพื้นฐาน)
• การใช้ JSF เพื่อพัฒนาเลย์เอาต์ CSS tableless (ตำนานเกี่ยวกับ JSF อื่น)
• JSF กับ HTML ธรรมดา / CSS / JS / jQuery (เมื่อ JSF เป็นตัวเลือกที่ผิด)
• รูปแบบการออกแบบในเว็บแอปพลิเคชัน (แสดงถึงอุดมการณ์เบื้องหลัง MVC)

หลังจากทำงานกับ JSF มา 5 ปีฉันคิดว่าฉันสามารถเพิ่ม 2 เซนต์ได้

ข้อเสียที่สำคัญของ JSFสองประการ:

1. โค้งการเรียนรู้ที่ยิ่งใหญ่ JSF นั้นซับซ้อนนั่นเป็นเรื่องจริง
2. ใช้องค์ประกอบธรรมชาติ เฟรมเวิร์กอิงองค์ประกอบพยายามซ่อนธรรมชาติที่แท้จริงของเว็บซึ่งมาพร้อมกับจำนวนมากของภาวะแทรกซ้อนและภัยพิบัติ (เช่นไม่สนับสนุน GET ใน JSF ภายในเกือบ 5 ปี)
   IMHO การซ่อนคำขอ HTTP / การตอบสนองจากผู้พัฒนาเป็นความผิดพลาดครั้งใหญ่ จากประสบการณ์ของฉันทุกเฟรมเวิร์กตามส่วนประกอบเพิ่มสิ่งที่เป็นนามธรรมให้กับการพัฒนาเว็บและสิ่งที่เป็นนามธรรมนั้นส่งผลให้เกิดค่าใช้จ่ายที่ไม่จำเป็นและความซับซ้อนที่สูงขึ้น

และข้อเสียเล็กน้อยที่อยู่ในใจของฉัน:

1. โดย ID เริ่มต้นของวัตถุประกอบด้วยรหัสพ่อแม่ของมันเช่น form1: button1
2. ไม่มีวิธีที่ง่ายในการแสดงความคิดเห็นส่วนที่ไม่ถูกต้องของหน้าเว็บ แท็ก<ui:remove>ต้องการเนื้อหาที่ถูกต้องทางไวยากรณ์ซึ่งแยกวิเคราะห์แล้ว
3. ส่วนประกอบของบุคคลที่สามที่มีคุณภาพต่ำเช่นไม่ได้ตรวจสอบวิธีการisRendered()ภายในprocessXxx()ก่อนดำเนินการต่อ
4. การผสมผสานระหว่าง LESS & Sencha นั้นยาก
5. เล่นได้ไม่ดีกับ REST
6. ไม่ใช่เรื่องง่ายนักสำหรับนักออกแบบ UX เนื่องจากส่วนประกอบที่พร้อมใช้งานมีสไตล์ CSS ของตัวเองที่ต้องเขียนทับ

อย่าเข้าใจฉันผิด ในฐานะที่เป็นเฟรมเวิร์กองค์ประกอบ JSF ในเวอร์ชัน 2 เป็นสิ่งที่ดีจริงๆ แต่ก็ยังคงยึดตามส่วนประกอบและจะเป็น ...

โปรดดูความนิยมต่ำของ Tapestry, Wicket และความกระตือรือร้นต่ำของนักพัฒนา JSF ที่มีประสบการณ์ (สิ่งที่มีความหมายมากยิ่งขึ้น) ลองดูความสำเร็จของ Rails, Grails, Django, Play! เฟรมเวิร์ก - ทั้งหมดเป็นแอคชั่นและไม่พยายามซ่อนจากคำขอ / การตอบสนองที่แท้จริงของโปรแกรมเมอร์และธรรมชาติของเว็บ

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

หวังว่ามันจะช่วยให้ใครบางคนที่มีตัวเลือกของเขา / เธอที่เกี่ยวข้องกับส่วนหน้า

ข้อเสียบางประการที่ควรคำนึงถึง:

1. JSF เป็นเฟรมเวิร์กอิงคอมโพเนนต์ สิ่งนี้มีข้อ จำกัด โดยธรรมชาติที่เกี่ยวข้องกับการเชื่อฟังแบบจำลองส่วนประกอบ
2. AFAIK JSF รองรับเฉพาะ POST เท่านั้นดังนั้นหากคุณต้องการ GET ที่ไหนสักแห่งคุณต้องทำ servlet / JSP ธรรมดา
3. ส่วนประกอบส่วนใหญ่พยายามที่จะให้ abstractions บนโดเมนเช่นฐานข้อมูลเชิงสัมพันธ์และ front-end JavaScript และหลายครั้งที่ abstractions เหล่านี้ "รั่ว" และยากที่จะดีบั๊ก
4. abstractions เหล่านี้อาจเป็นจุดเริ่มต้นที่ดีสำหรับนักพัฒนารุ่นเยาว์หรือคนที่ไม่พอใจกับโดเมนเฉพาะ (เช่น front-end JavaScript) แต่ยากมากที่จะปรับประสิทธิภาพให้เหมาะสมเนื่องจากมีหลายเลเยอร์ที่เกี่ยวข้องและคนส่วนใหญ่ที่ใช้พวกเขา มีความเข้าใจเพียงเล็กน้อยว่าเกิดอะไรขึ้นภายใต้ประทุน
5. กลไกการสร้างเท็มเพลตที่มักใช้กับ JSF ไม่มีส่วนเกี่ยวข้องกับการทำงานของเว็บ desigers บรรณาธิการ WYSIWYG สำหรับ JSF นั้นเป็นแบบดั้งเดิมและไม่ว่าในกรณีใดนักออกแบบของคุณจะให้ HTML / CSS แก่คุณซึ่งคุณจะต้องใช้เวลาในการแปลงนาน ๆ
6. สิ่งต่าง ๆ เช่นการแสดงออกของ EL ไม่ได้ถูกตรวจสอบแบบสแตติกและทั้งคอมไพเลอร์และ IDE จะทำงานได้ดีในการหาข้อผิดพลาดดังนั้นคุณจะพบข้อผิดพลาดที่คุณต้องดำเนินการ นี่อาจใช้ได้สำหรับภาษาที่พิมพ์แบบไดนามิกเช่น Ruby หรือ PHP แต่ถ้าฉันต้องทนต่อการขยายตัวของระบบนิเวศ Java ฉันต้องพิมพ์แม่แบบของฉัน

ในการสรุป:เวลาที่คุณจะบันทึกด้วย JSF จากการหลีกเลี่ยงการเขียนโค้ดแผ่นสำเร็จรูปของ JSP / servlet / bean คุณจะใช้เวลา x10 เพื่อทำให้มาตราส่วนและทำตามที่คุณต้องการ

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

• HTML ในสาขาต่าง ๆ อย่าแกล้งทำเป็นว่าคุณไม่จำเป็นต้องรู้
• HTTP - เมื่อคุณไม่สามารถทราบได้ว่าเกิดอะไรขึ้นคุณต้องเปิด Firebug แล้วดู เพื่อที่คุณจะต้องรู้สิ่งนี้
• CSS - ชอบหรือไม่ มันไม่ได้เลวร้ายจริงๆและมีเครื่องมือที่ดีอย่างน้อยก็อยู่ที่นั่น
• XML - JSF อาจเป็นที่แรกที่คุณใช้เนมสเปซในระดับนี้
• ข้อกำหนดของ servlet ไม่ช้าก็เร็วคุณจะได้รับวิธีการโทรในแพ็คเกจนี้ นอกเหนือจากนั้นคุณต้องรู้ว่า Facelets ของคุณจะกลายเป็น XHTML หรืออะไรก็ตาม
• JSP (ส่วนใหญ่เพื่อให้คุณรู้ว่าทำไมคุณไม่ต้องการใน JSF)
• JSTL (อีกครั้งส่วนใหญ่เพื่อรับมือกับกรอบงานดั้งเดิม)
• Expression Language (EL) ในรูปแบบต่าง ๆ
• ECMAScript, JavaScript หรืออะไรก็ได้ที่คุณต้องการโทรหา
• JSON - คุณควรรู้สิ่งนี้แม้ว่าคุณจะไม่ได้ใช้มัน
• AJAX ฉันจะบอกว่า JSF 2.0 ทำงานได้ดีในการซ่อนสิ่งนี้จากคุณ แต่คุณยังต้องรู้ว่าเกิดอะไรขึ้น
• DOM และวิธีที่เบราว์เซอร์ใช้งาน ดู ECMAScript
• กิจกรรม DOM - หัวข้อทั้งหมดด้วยตัวเอง
• Java Persistence Architecture (JPA) นั่นคือถ้าคุณต้องการให้แอปของคุณมีฐานข้อมูลส่วนหลัง
• จาวาตัวเอง
• JSEE ขณะที่คุณอยู่ที่นั้น
• ข้อมูลจำเพาะ Context Dependency Injection (CDI) และวิธีที่ขัดแย้งกับและใช้กับ JSF 2.0
• JQuery - ฉันอยากเห็นคุณเข้าไม่ได้

ทีนี้เมื่อคุณทำเสร็จแล้วคุณจะได้รับข้อมูลจำเพาะที่เป็นกรรมสิทธิ์คือไลบรารีส่วนประกอบและไลบรารีผู้ให้บริการที่คุณจะไปตามทาง:

• PrimeFaces (ไลบรารีคอมโพเนนต์ของฉันที่เลือก)
• RichFaces
• MyFaces
• ICEfaces
• EclipseLink (ผู้ให้บริการ JPA ของฉัน)
• Hibernate
• เชื่อม

และอย่าลืมภาชนะ! และไฟล์การกำหนดค่าเหล่านั้นทั้งหมด:

• GlassFish (2, 3, ฯลฯ )
• JBoss
• แมวตัวผู้

ดังนั้น - นี่ทำให้ง่ายขึ้นไหม? แน่นอนว่า JSF 2.0 นั้น "ง่าย" ตราบใดที่คุณต้องการทำคือหน้าเว็บพื้นฐานที่สุดที่มีการโต้ตอบที่ง่ายที่สุด

กล่าวง่ายๆ JSF 2.0 เป็นเทคโนโลยีที่ซับซ้อนและยุ่งยากที่สุดในการผสานเทคโนโลยีที่มีอยู่ในจักรวาลซอฟต์แวร์ในปัจจุบัน และฉันไม่สามารถคิดอะไรที่ฉันอยากจะใช้

1. นักพัฒนาที่ไม่มีประสบการณ์มักจะสร้างแอปพลิเคชันที่เจ็บปวดช้าและรหัสจะน่าเกลียดและยากที่จะรักษา มันง่ายที่จะเริ่มหลอกลวง แต่จริงๆแล้วมันต้องการการลงทุนในการเรียนรู้ถ้าคุณต้องการเขียนโปรแกรมที่ดี
2. อย่างน้อยในช่วงเริ่มต้นคุณมักจะ "ติด" กับปัญหาบางอย่างและจะใช้เวลาอ่านโพสต์บาลานในอินเทอร์เน็ตมากกว่าการใช้งานจริง :) หลังจากผ่านไปสักครู่มันจะน้อยลง แต่มันก็น่ารำคาญ
3. น่ารำคาญยิ่งขึ้นเมื่อคุณพบว่าปัญหาไม่ได้เกิดจากการที่คุณขาดความรู้ / ความผิดพลาด แต่จริงๆแล้วเป็นข้อผิดพลาด Mojarra เป็นรถม้าที่ค่อนข้างเยอะและส่วนประกอบอีกชั้นเพิ่มปัญหามากขึ้น Richfaces เป็นซอฟต์แวร์อึที่ใหญ่ที่สุดเท่าที่เคยเขียนมา :) ไม่ทราบว่าตอนนี้เป็นเวอร์ชัน 4 เรามี Primefaces ที่ดีกว่า แต่คุณยังคงพบข้อผิดพลาดหรือขาดคุณสมบัติโดยเฉพาะกับส่วนประกอบที่แปลกใหม่ และตอนนี้คุณจะต้องจ่ายเงินสำหรับการอัพเดท Primefaces ดังนั้นฉันจะบอกว่ามันเป็นบั๊กซี แต่มันดีขึ้นโดยเฉพาะหลังจากเวอร์ชัน 2.2 แก้ไขปัญหาบางอย่างกับสเป็ค เฟรมเวิร์กมีความเป็นผู้ใหญ่มากขึ้น แต่ยังห่างไกลจากความสมบูรณ์แบบ
4. ฉันไม่พบว่ามันยืดหยุ่นเป็นพิเศษ บ่อยครั้งถ้าคุณต้องการบางสิ่งบางอย่างที่กำหนดเองมากและไม่มีองค์ประกอบที่ทำเช่นนั้น - มันจะเจ็บปวดเล็กน้อย อีกครั้งฉันกำลังพูดถึงมุมมองของนักพัฒนาโดยเฉลี่ย - คนที่มีกำหนดส่งแบบฝึกหัดการอ่านอย่างรวดเร็วและค้นหา stackoverflow เมื่อติดขัดเพราะไม่มีเวลาเรียนรู้วิธีการใช้งานจริง ๆ :) ส่วนประกอบบางอย่างดูเหมือนจะมี "เกือบ" สิ่งที่คุณต้องการ แต่ ไม่แน่นอนและบางครั้งคุณอาจใช้เวลามากเกินไปในการทำสิ่งที่คุณต้องการ :) ต้องระมัดระวังในการประเมินว่ามันดีกว่าที่จะสร้างองค์ประกอบของคุณเองหรือทรมานองค์ประกอบที่มีอยู่ จริง ๆ แล้วถ้าคุณกำลังสร้างบางสิ่งที่แปลกใหม่จริง ๆ ฉันจะไม่แนะนำ JSF

ดังนั้นในระยะสั้นข้อเสียของฉันจะเป็น: ความซับซ้อน, ความคืบหน้าการพัฒนาไม่ราบรื่นมาก, รถ, ยืดหยุ่น

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

"JSF จะแสดง HTML และ JavaScript ของวิวเลเยอร์ที่คุณไม่สามารถควบคุมหรือเปลี่ยนแปลงได้โดยไม่ต้องใช้โค้ดควบคุม"

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

ฉันไม่ใช่ผู้เชี่ยวชาญเซิร์ฟเวอร์ Java ใบหน้าเลย แต่ IMHO ข้อเสียเปรียบหลักก็คือฝั่งเซิร์ฟเวอร์ ฉันเบื่อที่จะเรียนรู้และใช้งานเลเยอร์เฟรมเวิร์กการนำเสนอทางฝั่งเซิร์ฟเวอร์เช่น ASP.NET Web Forms, ASP.NET MVC, Java Server Faces, Struts, php framework และ ruby ​​บนเฟรมเวิร์ก Rails ฉันบอกลาพวกเขาทั้งหมดและกล่าวสวัสดีกับ Angularjs และ TypeScript เลเยอร์การนำเสนอของฉันทำงานบนเบราว์เซอร์ ฉันไม่สำคัญว่าจะให้บริการโดย Windows IIS ที่ใช้งาน php หรือ ASP.NET หรือไม่ก็ตามหากเว็บเซิร์ฟเวอร์ Apache ให้บริการบน Linux ฉันแค่ต้องเรียนรู้กรอบเดียวที่ทำงานได้ทุกที่

แค่สองเซ็นต์ของฉัน

เราพัฒนาโครงการตัวอย่างกับ JSF (เป็นการวิจัยสามสัปดาห์ดังนั้นเราอาจสูญเสียบางสิ่ง!)

เราพยายามใช้ core jsf หากต้องการส่วนประกอบเราใช้ PrimeFaces

โครงการนี้เป็นเว็บไซต์พร้อมการนำทาง แต่ละหน้าควรโหลดผ่าน ajax เมื่อมีการคลิกเมนู

ไซต์มีสอง usecases:

1. หน้าเว็บที่มีกริด โหลดกริดผ่าน ajax และควรรองรับการเรียงลำดับและการเพจ
2. หน้าตัวช่วยสร้างสามขั้นตอน แต่ละหน้ามีการตรวจสอบด้านลูกค้า (สำหรับการตรวจสอบง่าย) และการตรวจสอบฐาน ajax ฝั่งเซิร์ฟเวอร์ (สำหรับการตรวจสอบที่ซับซ้อน) ข้อยกเว้นเซิร์ฟเวอร์ใด ๆ (จากชั้นบริการ) ควรจะแสดงในหน้าตัวช่วยสร้างเดียวกันโดยไม่ต้องไปที่หน้าถัดไป

เราพบว่า:

1. คุณต้องใช้แฮ็กจาก omniFaces เพื่อทำให้สถานะมุมมอง JSF คงที่ สถานะ JSF จะเสียหายเมื่อคุณรวมหน้าผ่าน ajax ในกันและกัน นี่ดูเหมือนว่าบั๊กใน JSF และอาจได้รับการแก้ไขในรีลีสถัดไป (ไม่ใช่ใน 2.3)
2. JSF Flow ทำงานไม่ถูกต้องกับ ajax (หรือเราไม่สามารถทำงานได้!) เราพยายามใช้ส่วนประกอบตัวช่วยสร้าง Primeface แทน แต่การตรวจสอบความถูกต้องของไคลเอนต์ดูเหมือนจะไม่ได้รับการสนับสนุนและค่าเฉลี่ยในขณะที่ไม่ใช่มาตรฐานการไหล JSF มาตรฐาน
3. เมื่อใช้ส่วนประกอบ jQuery บางอย่างเช่น jqGird และคุณต้องโหลดผลลัพธ์ JSON คุณควรใช้ servlet แท้ JSF จะไม่ทำอะไรให้คุณเลย ดังนั้นหากคุณใช้ส่วนประกอบประเภทนี้การออกแบบของคุณจะไม่เหมาะสมใน JSF
4. เราพยายามทำสคริปต์ลูกค้าเมื่ออาแจ็กซ์ดำเนินการจนเสร็จสิ้นajaxCompleteและเราพบว่า PF 4 ได้ดำเนินกิจกรรมอาแจ็กซ์ของตนเอง เรามีส่วนประกอบ jQuery และเราจำเป็นต้องเปลี่ยนรหัส

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

เราสรุปงานวิจัยของเราเป็น:

JSF ทำงานได้ไม่ดีในเว็บไซต์ ajax อย่างสมบูรณ์

แน่นอนว่าเราพบฟีเจอร์ที่ดีมากมายใน JSF ซึ่งอาจเป็นประโยชน์ในบางโครงการดังนั้นพิจารณาความต้องการของโครงการของคุณ

โปรดอ้างอิงเอกสารทางเทคนิคของ JSF เพื่อตรวจสอบข้อดีของ JSF และในความคิดของฉันคือข้อได้เปรียบที่ใหญ่ที่สุดของ JSF คือการสนับสนุนที่สมบูรณ์และยิ่งใหญ่จาก @BalusC ;-)

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

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

แต่ดูเหมือนว่าชุมชน JSF จะตระหนักถึงข้อบกพร่องนี้ พวกเขากำลังทำงานเกี่ยวกับเรื่องนี้ในขณะที่คุณสามารถดูจากทั้งสองข้อบกพร่อง
http://java.net/jira/browse/JAVASERVERFACES-1309
http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-599

สถานการณ์ควรดีขึ้นด้วย JSF 2.2 อย่างน้อยถ้าเรากำลังพูดถึงสเปค

แสดงความคิดเห็นในช่วงสองสามเดือนสุดท้ายของประสบการณ์ Primefaces / JSF ของฉัน:

• หากคุณสามารถใช้ส่วนประกอบ "ปิดชั้นวาง" ฉันคิดว่ามันไม่น่ากลัว
• อย่างไรก็ตามมันเล่นได้ไม่ดีทันทีที่คุณออกไปข้างนอกและต้องการ UIs ที่กำหนดเอง - ตัวอย่างเช่นเราจำเป็นต้องใช้ bootstrap ของ Twitter สำหรับโครงการของเรา (ไม่ใช่บูตแฟล็กแฟล็ก)
  • ตอนนี้หน้าของเราทำงานดังนี้:
    • โหลดหน้าเว็บ
    • ผู้ใช้โต้ตอบกับ Primefaces ที่มีฟังก์ชั่น ajax
    • javascript ของ Bootstrap นั้นผิดพลาด
    • เราเรียกใช้จาวาสคริปต์พิเศษเพื่อปฏิเสธทุกสิ่ง

คำสัญญาของ JSF เพื่อหลีกเลี่ยงการเขียนจาวาสคริปต์กลายเป็นการเขียนจาวาสคริปต์มากกว่าที่เราจะได้ถ้าไม่ใช้ Primefaces - และจาวาสคริปต์นั้นเพื่อแก้ไขสิ่งที่ Primefaces แตก

มันเป็นช่วงเวลา - เว้นแต่คุณจะใช้สิ่งที่ "ปิดชั้น" อีกครั้ง ก็น่าเกลียดจริงๆ (Primefaces) เมื่อต้องทำงานกับซีลีเนียม สามารถทำได้ทั้งหมด - แต่อีกครั้ง - มีเวลามากเท่านั้น

หลีกเลี่ยงสิ่งนี้อย่างแน่นอนหากคุณทำงานกับ UX / ทีมออกแบบและจำเป็นต้องทำซ้ำอย่างรวดเร็วบน UI - คุณสามารถประหยัดเวลาได้ด้วยการเรียนรู้ jquery / เขียน HTML ตรง - หรือดูปฏิกิริยา / เชิงมุม

JSF มีข้อดีหลายอย่างคำถามอยู่ในข้อเสียขอฉันเพิ่มจุดสองสามข้อ

ในสถานการณ์จริงของการนำโครงการเว็บไปใช้ในกรอบเวลาคุณต้องจับตามองปัจจัยต่อไปนี้

• คุณมีสมาชิกอาวุโสเพียงพอในทีมของคุณที่สามารถแนะนำการควบคุมที่เหมาะสมที่สุดสำหรับแต่ละสถานการณ์หรือไม่

• คุณมีแบนด์วิดท์เพื่อรองรับโค้งการเรียนรู้เริ่มต้นหรือไม่?

• คุณมีความเชี่ยวชาญเพียงพอในทีมของคุณที่สามารถตรวจสอบ
  สิ่งที่JSF สร้างขึ้นโดยนักพัฒนาหรือไม่?

หากคำตอบของคุณคือ 'ไม่' สำหรับคำถามคุณอาจลงเอยด้วยฐานข้อมูลที่ไม่สามารถบำรุงรักษาได้

JSF มีข้อเสียเพียงข้อเดียวเท่านั้น: ก่อนที่จะเริ่มการพัฒนา "JSF" คุณควรเข้าใจการพัฒนาเว็บ, core java และสถาปัตยกรรม front-end อย่างชัดเจน

ทุกวันนี้เฟรมเวิร์ก JavaScript "ใหม่" เพียงลองคัดลอก / วางโมเดลที่อิงกับคอมโพเนนต์ "JSF"

ในกรอบ "กระแสหลัก" ทั้งหมดเช่น Spring MVC, Wicket, Tapestry เป็นต้น JSF ของ Java EE พร้อมองค์ประกอบคอมโพสิตเป็นเทคโนโลยีการนำเสนอเลเยอร์และเทคโนโลยีเชิงส่วนประกอบที่มีความละเอียดมากที่สุด มันค่อนข้างยุ่งยากและไม่สมบูรณ์เมื่อเทียบกับโซลูชั่นที่ให้บริการโดย HybridJava