ฉันกำลังเริ่มโปรเจ็กต์ใหม่ตอนนี้ ฉันต้องเลือกเทคโนโลยี ฉันต้องการอะไรบางอย่างที่เบาดังนั้นจึงไม่มี EJB หรือ Seam ในทางกลับกันฉันต้องการ JPA (Hibernate หรือทางเลือกอื่น) และ JSF พร้อม IceFaces
คุณคิดว่าสแต็กใน Spring 3 ที่ติดตั้งบน Tomcat เป็นตัวเลือกที่ดีหรือไม่? หรือเว็บแอปพลิเคชัน Java EE 6 น่าจะดีกว่านี้? ฉันกลัวว่า Java EE 6 เป็นเทคโนโลยีใหม่ยังไม่ได้รับการจัดทำเป็นเอกสารอย่างดี Tomcat ดูเหมือนจะดูแลรักษาง่ายกว่า Glassfish 3
ความคิดเห็นของคุณคืออะไร? คุณมีประสบการณ์หรือไม่?
คำตอบ:
ฉันต้องการอะไรบางอย่างที่เบาดังนั้นจึงไม่มี EJB หรือ Seam
คุณช่วยอธิบายได้ไหมว่าอะไรทำให้ EJB หนักตั้งแต่ EJB3 คุณรู้หรือไม่ว่าเราไม่ได้อยู่ในปี 2004 อีกต่อไป? ที่ผมต้องการที่จะอ่านของคุณความหมายของแสงและข้อโต้แย้งของคุณ (และฉันจะปรับปรุงคำตอบของฉันมีความสุขเพราะผมค่อนข้างมั่นใจว่าผมจะมีสิ่งที่เป็นของแข็งไม่กี่ที่จะพูด)
ในทางกลับกันฉันต้องการ JPA (Hibernate หรือทางเลือกอื่น) และ JSF พร้อม IceFaces
Java EE 6 Web Profile ซึ่งรวมถึง JSF 2.0, JPA 2.0, Bean Validation, EJB 3.1 Lite, CDI, ... จะเหมาะสำหรับสิ่งนี้และคุณสามารถใช้GlassFish v3 Web Profileเพื่อเรียกใช้แอปพลิเคชันที่สร้างขึ้นด้วย Java EE 6 Web Profile .
คุณคิดว่าสแต็คใน Spring 3 ที่ติดตั้งบน Tomcat เป็นตัวเลือกที่ดีหรือไม่? หรือเว็บแอปพลิเคชัน Java EE 6 น่าจะดีกว่านี้?
ดีผมชอบความคิดที่จะเรียกใช้รหัสของฉันในที่ไม่เป็นกรรมสิทธิ์แพลตฟอร์ม (Java EE) มากกว่าในภาชนะที่เป็นกรรมสิทธิ์ (ฤดูใบไม้ผลิ) และฉันคิดว่า Java EE 6 นั้นดีพอ (และนี่คือคำสละสลวย, EJB 3.1 (Lite), JPA 2.0, JSF 2.0, CDI kick ass) โปรดทราบว่าฉันเป็นคนขี้ระแวง JSF แต่ฉันลองดูครั้งที่สองและ JSF 2.0 กับ CDI นั้นแตกต่างกันมากจนฉันไม่สามารถเปรียบเทียบได้ และถ้าคุณไม่ได้ดู CDI ขอบอกเลยว่ามันเป็นเรื่องที่น่าสนใจ
ฉันกลัวว่า Java EE 6 เป็นเทคโนโลยีใหม่ยังไม่ได้รับการจัดทำเป็นเอกสารอย่างดี
Java EE ดูเป็นเอกสารที่ดีสำหรับฉัน ฟังดูเหมือนอ้างสิทธิ์ฟรี และเชื่อฉันหรือไม่ว่าฉันเริ่มพบว่า Spring เริ่มซับซ้อนในขณะที่ Java EE เริ่มง่ายขึ้น
Tomcat ดูเหมือนจะดูแลรักษาง่ายกว่า Glassfish 3
คุณลองอะไรหรือเปล่า? คุณประสบปัญหาใดเป็นพิเศษหรือไม่? อีกครั้งดูเหมือนการอ้างสิทธิ์ฟรี
ฉันไม่ได้ใช้ JavaEE6
อย่างไรก็ตามฉันได้รับความเสียหายอย่างมากจาก JavaEE และ EJB เวอร์ชันก่อนหน้าทั้งหมดที่ฉันจะไม่ไว้วางใจจนกว่ามันจะสร้างตัวเองเป็นมาตรฐานโดยพฤตินัยไม่ใช่แค่มาตรฐานทางนิตินัย ตอนนี้สปริงยังคงเป็นมาตรฐานโดยพฤตินัย
หลอกฉันครั้งเดียวทำให้คุณอับอาย หลอกฉันสองครั้งทำให้ฉันอับอาย หลอกฉันสามครั้ง EJB
บางคนจะอ้างว่า Spring เป็นกรรมสิทธิ์ ฉันจะโต้แย้งว่าการใช้งานข้อกำหนด JavaEE ของผู้ขายนั้นเป็นกรรมสิทธิ์ของผู้ขายหากไม่เป็นเช่นนั้น
เมื่อเร็ว ๆ นี้ฉันได้ทำการแปลงครั้งใหญ่ในการย้ายแอปพลิเคชัน Java จำนวนมากจาก JBoss ไปยัง Weblogic แอป Spring / Hibernate ทั้งหมดมีการปรับเปลี่ยนเป็นศูนย์เนื่องจากมีไลบรารีทั้งหมดที่ต้องการในตัวแอปทั้งหมดที่ใช้ JPA และ EJB และ JSF เป็นภัยพิบัติในการพอร์ต ความแตกต่างเล็กน้อยในการตีความ JPA, EJB และ JSF ระหว่างแอปเซิร์ฟเวอร์ทำให้เกิดข้อบกพร่องที่น่ารังเกียจทุกประเภทซึ่งต้องใช้เวลาแก้ไขตลอดไป แม้แต่บางสิ่งที่เรียบง่ายอย่างการตั้งชื่อ JNDI ก็แตกต่างกันอย่างสิ้นเชิงระหว่าง AppServers
ฤดูใบไม้ผลิเป็นการนำไปใช้ JavaEE เป็นข้อมูลจำเพาะ นั่นคือความแตกต่างอย่างมาก ฉันต้องการใช้ข้อมูลจำเพาะหากข้อมูลจำเพาะมีอากาศแน่น 100% และไม่มีพื้นที่กระดิกอย่างแน่นอนในวิธีที่ผู้ขายใช้ข้อกำหนดนั้น แต่ข้อมูลจำเพาะ JavaEE ไม่เคยเป็นเช่นนั้น บางที JavaEE6 จะแน่นกว่า? ฉันไม่รู้ ยิ่งคุณสามารถจัดแพคเกจใน WAR ของคุณได้มากเท่าไหร่และคุณก็ต้องพึ่งพาไลบรารี AppServer น้อยลงแอปพลิเคชันของคุณก็จะพกพาได้มากขึ้นและนั่นคือเหตุผลที่ฉันใช้ Java ไม่ใช่ Dot-NET
แม้ว่าข้อมูลจำเพาะจะแน่นมาก แต่ก็เป็นการดีที่จะสามารถอัปเกรดเซิร์ฟเวอร์แอปได้โดยไม่ต้องอัปเกรดสแต็คเทคโนโลยีทั้งหมดในแอปพลิเคชันทั้งหมดของฉันควบคู่ไปด้วย หากฉันต้องการอัปเกรดจาก JBoss 4.2 เป็น JBoss 7.0 ฉันต้องพิจารณาผลกระทบของ JSF เวอร์ชันใหม่ที่มีต่อแอปพลิเคชันทั้งหมดของฉัน ฉันไม่ต้องพิจารณาผลกระทบต่อแอปพลิเคชัน Spring-MVC (หรือ Struts) ของฉัน
มันไม่สำคัญหรอก Java EE 6 ดีพอและเนื่องจากโปรไฟล์ที่นั่นจึงไม่ "หนัก" - คุณแค่ใช้โปรไฟล์เว็บ
โดยส่วนตัวแล้วฉันชอบฤดูใบไม้ผลิมากกว่า แต่ฉันไม่มีข้อโต้แย้งที่เป็นเหตุเป็นผลกับ Java EE 6 :)
(ตามที่ฉันได้รับการเตือนจากความคิดเห็นคุณอาจต้องการลองใช้RichFacesเช่นเดียวกับICEfacesและ / หรือPrimeFacesขึ้นอยู่กับส่วนประกอบที่คุณต้องการ)
เมื่อเร็ว ๆ นี้หนึ่งในงานมอบหมายไคลเอ็นต์ของฉันเกี่ยวข้องกับการประเมิน Spring Stack Vs Custom framework stack เทียบกับ Java EE Standards หลังจากผ่านไปหนึ่งเดือนของการประเมินผลและการสร้างต้นแบบฉันไม่เพียงแค่มีความสุข แต่ประทับใจกับชุดคุณสมบัติ Java EE 6 สำหรับสถาปัตยกรรมโครงการ "องค์กร" ใหม่ ๆ ในปี 2554 และในอนาคตฉันจะใช้ Java EE 6 และส่วนขยายที่เป็นไปได้เช่น Seam 3 หรือโครงการส่วนขยาย Apache JSR299 ที่กำลังจะมีขึ้น สถาปัตยกรรม Java EE 6 มีความคล่องตัวและรวมเอาแนวคิดโอเพ่นซอร์สที่ดีที่สุดจำนวนมากที่พัฒนาขึ้นในช่วงหลายปีที่ผ่านมา
พิจารณาคุณลักษณะต่อไปนี้นอกกรอบ: Event Management, Contexts and DI, Interceptors, Decorators, RESTful webservices, Integrated testing with embeddable container, Security และอื่น ๆ อีกมากมาย
ผลลัพธ์ส่วนใหญ่ของฉันได้รับการเผยแพร่ในบล็อกของฉันเพื่ออธิบายแนวคิดหลักของ Java EE 6 ที่คุณอาจพบว่ามีประโยชน์
แน่นอนว่าไม่มีกฎที่ยากและรวดเร็วในการเลือกกรอบงาน Java EE 6 อาจใช้งานได้ดีสำหรับ "เว็บไซต์" ที่เรียบง่ายซึ่งไม่ต้องการสถานะเซสชันการสนทนาที่สมบูรณ์ คุณอาจเลือก Grails หรือ Play ก็ได้! กรอบ. แต่สำหรับเว็บแอปพลิเคชันการสนทนาฉันไม่เห็นข้อโต้แย้งที่ดีกว่าว่าทำไม Java EE 6 จึงไม่เหมาะสม
หลังจากนั้นไม่นานฉันมีประสบการณ์กับสแต็ค:
colclusions ของฉันคือ:
อ่านFuture Of Enterprise Java ของ Adam Bien ... Is Clear (Java EE ที่มี / ไม่มี Spring และ Vice Versa)รวมถึงความคิดเห็นเพื่อรับเหรียญทั้งสองด้าน ฉันจะเลือก Spring ด้วยเหตุผลหลายประการและต่อไปนี้เป็นหนึ่งในนั้น (สร้างความคิดเห็นจากโพสต์ใหม่)
'ฉันไม่แน่ใจว่าเซิร์ฟเวอร์ Java EE 6 ใดที่คุณกำลังพูดถึง มี Glassfish ได้รับการรับรองและ TMAX JEUS จะใช้เวลาสักครู่ (อ่าน: ปี) จนกว่า WebSphere, WebLogic, JBoss และเวอร์ชันที่รองรับ Java EE 6 จะอยู่ในระหว่างการผลิตและสามารถใช้สำหรับแอปพลิเคชันจริงได้ Spring 3 ต้องการ Java 1.5 และ J2EE 1.4 เพื่อให้สามารถใช้งานได้ในเกือบทุกสภาพแวดล้อม
ความคิดเห็นของฉันขึ้นอยู่กับสิ่งที่คนอื่นไม่ได้กล่าวถึงกล่าวคือรหัสในที่ทำงานของฉันมักจะอยู่ได้หลายทศวรรษ (ตามตัวอักษร) และด้วยเหตุนี้การบำรุงรักษาจึงมีความสำคัญต่อเรา การบำรุงรักษารหัสของเราเองและไลบรารีที่เราใช้ รหัสของเราเองที่เราควบคุม แต่เพื่อประโยชน์ของเราว่าห้องสมุดที่เราใช้นั้นได้รับการดูแลโดยผู้อื่นในทศวรรษที่กล่าวมา
ในการสร้างเรื่องสั้นให้สั้นฉันได้ข้อสรุปแล้วว่าวิธีที่ดีที่สุดในการบรรลุเป้าหมายนี้คือการใช้โอเพนซอร์สของข้อกำหนดของ Sun จนถึง JVM แบบดิบ
จากการใช้งานโอเพนซอร์ส Apache Jakarta ได้พิสูจน์แล้วว่าสามารถดูแลรักษาห้องสมุดของตนได้และเมื่อเร็ว ๆ นี้ Sun ได้ทำงานมากมายในการผลิตการใช้งานที่มีคุณภาพสูงสำหรับ Glassfish v3 ไม่ว่าในกรณีใดเรายังมีแหล่งที่มาสำหรับโมดูลทั้งหมดดังนั้นหากทุกอย่างล้มเหลวเราสามารถดูแลโมดูลเหล่านั้นได้ด้วยตนเอง
ข้อมูลจำเพาะของดวงอาทิตย์มักจะมีความหมายที่เข้มงวดมากซึ่งการใช้งานที่เป็นไปตามข้อกำหนดสามารถเปลี่ยนแปลงได้อย่างง่ายดาย เพียงแค่ดูที่คอนเทนเนอร์ servlet
ในกรณีนี้ฉันขอแนะนำให้ดูที่ JavaServer Faces เพียงเพราะเป็นส่วนหนึ่งของ Java EE 6 ซึ่งหมายความว่าจะพร้อมใช้งานและคงไว้เป็นเวลานานมาก จากนั้นเราได้เลือกที่จะเพิ่มด้วย MyFaces Tomahawk เนื่องจากมีส่วนเพิ่มเติมที่เป็นประโยชน์และเป็นโครงการจาการ์ตา
ไม่มีอะไรผิดปกติกับ JBoss Seam หรืออื่น ๆ เป็นเพียงการที่พวกเขาให้ความสำคัญกับปัญหาการบำรุงรักษาที่สำคัญสำหรับเราน้อยลง
ฉันสามารถใช้ Spring ได้ถ้าคุณมีอยู่แล้ว แต่สำหรับโปรเจ็กต์ใหม่ประเด็นคืออะไร? ฉันจะใช้ Java EE 6 โดยตรง (ejb3, jsf2.0 ฯลฯ )
ถ้าลูกค้าสบายดีกับ Flex ไปได้เลย ใช้ BlazeDS หรือคล้ายกัน - ไม่มี mvc คุณอาจใช้เวลาในส่วนนั้นมากขึ้น (แลกเปลี่ยนข้อมูลระหว่างเซิร์ฟเวอร์และไคลเอนต์) แต่คุณสามารถควบคุมทั้งสองด้าน
อย่าใช้ Vaadin เว้นแต่คุณต้องการฆ่าเบราว์เซอร์ของคุณ นอกจากนี้คุณยังใช้เวลามากขึ้นในการแก้ไขโค้ดเมื่อหน้าเว็บของคุณซับซ้อนขึ้น นอกจากนี้ความคิดของคุณจะต้องเปลี่ยนไปอย่างสิ้นเชิงและสิ่งที่คุณรู้เกี่ยวกับการพัฒนาส่วนหน้ามาตรฐานจะเสียเปล่า อาร์กิวเมนต์ที่คุณไม่ต้องใช้ HTML หรือ JS นั้นไม่สมเหตุสมผลมากนัก คุณยังต้องรู้แม้ว่าคุณจะไม่ได้ใช้มันก็ตาม ในที่สุดจะแสดงผลเป็น HTML และ JS จากนั้นลองดีบัก - ตรวจสอบให้แน่ใจว่าคุณมีเวลาไม่กี่วันสำหรับสิ่งง่ายๆ นอกจากนี้ฉันนึกภาพไม่ออกว่านักพัฒนาเว็บที่ไม่รู้จัก html / js
ฉันไม่เข้าใจว่าทำไมผู้คนถึงลองใช้ abstractions ทั้งหมดแทนที่จะใช้ Java EE โดยตรง
เหตุใดจึงยังคงมีคำครึกโครมเกี่ยวกับ EJB ที่เป็นรุ่นหนาในปี 2010 ดูเหมือนว่าผู้คนจะไม่ได้รับการอัปเดตในเทคโนโลยี Java EE เพียงแค่ลองใช้งานคุณจะประหลาดใจอย่างมากว่าสิ่งต่าง ๆ ถูกทำให้ง่ายขึ้นใน Java EE 6 ได้อย่างไร
คำตอบสำหรับคำถามของคุณขึ้นอยู่กับข้อกำหนดโครงการของคุณ หากคุณไม่ต้องการคุณสมบัติ Java EE เช่นคิวข้อความคอนเทนเนอร์ที่มีการจัดการธุรกรรมส่วนกลาง ฯลฯ ให้ใช้ tomcat + spring
จากประสบการณ์ฉันพบว่าโครงการที่ต้องการการรวมบริการเว็บการตั้งเวลาคิวข้อความทำได้ดีที่สุดโดยใช้สแต็ก Java EE บางส่วน สิ่งที่ดีคือการใช้สปริงคุณยังสามารถรวมกับโมดูล Java EE ที่ทำงานในแอปพลิเคชันเซิร์ฟเวอร์ได้
Java EE 6 แตกต่างจากรุ่นก่อนหน้ามากและทำให้ทุกอย่างง่ายขึ้นมาก Java EE 6 ผสมผสานแนวคิดที่ดีที่สุดจากชุมชน Java ที่หลากหลายตัวอย่างเช่น Rod Johnson จาก Spring framework มีส่วนร่วมอย่างแข็งขันในการสร้าง Dependency Injection JSR ใน Java EE 6 ประโยชน์ของการใช้ Java EE 6 คือคุณกำลังเขียนโค้ดตาม มาตรฐานซึ่งอาจมีความสำคัญในบางองค์กรสำหรับการสนับสนุนผู้ขายเป็นต้น
GlassFish v3 รองรับ Java EE 6 และมีน้ำหนักเบาและเริ่มต้นได้เร็วมาก ฉันใช้ glassfish v3 ในการพัฒนาของฉันและมันง่ายมากที่จะกำหนดค่า มาพร้อมกับคอนโซลผู้ดูแลระบบที่ใช้งานง่ายมากซึ่งช่วยให้คุณจัดการเซิร์ฟเวอร์ของคุณแบบกราฟิก
หากคุณใช้ GlassfishV3 และ JSF 2 คุณสามารถใช้ประโยชน์จากคุณสมบัติ CDI ของ Java EE 6 ที่ช่วยให้คุณสร้างการสนทนาได้อย่างง่ายดาย (เช่นวิซาร์ดเช่นเพจ) ใน JSF
ต้องบอกว่าการใช้ Java EE 6 ทำให้คุณต้องเรียนรู้ API ใหม่ด้วย อาจไม่ใช่ทางเลือกที่ดีที่สุดสำหรับคุณทั้งนี้ขึ้นอยู่กับระยะเวลาที่มี Tomcat มีมานานแล้วและการผสมผสานระหว่าง tomcat + spring ถูกนำมาใช้โดยโครงการเว็บจำนวนมากซึ่งหมายความว่ามีเอกสาร / ฟอรัมมากมาย
ฉันทำงานทั้งใน Spring และ Java EE 6 สิ่งที่ฉันสามารถพูดได้จากประสบการณ์ของฉันก็คือถ้าคุณกำลังจะอายุมากขึ้น JSP หรือ Flex ที่เป็นกรรมสิทธิ์คุณจะปลอดภัยถ้าคุณอยู่กับ Spring
แต่ถ้าคุณต้องการก้าวไปข้างหน้าด้วย JSF ก็ถึงเวลาเปลี่ยนไปใช้ Java EE 6 ด้วย Java EE 6 คุณกำลังจะย้ายไปที่ Facelets และไลบรารีสคริปต์มาตรฐานและไลบรารีคอมโพเนนต์ ไม่มีความเข้ากันไม่ได้ของสคริปต์และเมทริกซ์ไลบรารีคอมโพเนนต์อีกต่อไป
เกี่ยวกับ Spring MVC เป็นสิ่งที่ดีตราบเท่าที่โครงการของคุณไม่ใหญ่เกินไป หากเป็นแอปพลิเคชันระดับองค์กรขนาดใหญ่ที่ยึดติดกับ Java EE 6 เพราะนั่นเป็นวิธีเดียวที่คุณสามารถรักษาไลบรารีคอมโพเนนต์ของคุณเองและบันเดิลทรัพยากรได้อย่างเป็นระเบียบ
หากคุณต้องการ Java EE แบบเต็มสแต็กฉันขอแนะนำให้คุณใช้ GlassFish 3.1 เริ่มต้นเร็วมากเมื่อเทียบกับคอนเทนเนอร์ Java EE อื่น ๆ ซึ่งใช้ Java EE 6 บางส่วนหรือทั้งหมด (JBoss 6, WebLogic 10.3.4) การปรับใช้ใหม่ใช้เวลาไม่กี่วินาทีและเกือบทั้งหมดสามารถทำได้โดยการประชุมผ่านการกำหนดค่ามันเป็นมิตรมาก
ฉันต้องการบางอย่าง "แสง" คุณสามารถปรับแต่ง Apache Tomcat 7.x ด้วยคุณสมบัติที่ต้องการได้ ฉันใช้จำนวนมากกับไลบรารีต่อไปนี้: Weld 1.1.0 (CDI) JPA 2.0 (Hibernate 3.6.x) - รีซอร์สเฉพาะธุรกรรมในเครื่อง JSF 2.x (Mojarra) RichFaces 4.0 BIRT runtime
เป็นนักพัฒนา Java EE ในช่วง 10 ปีที่ผ่านมา (ฉันประสบปัญหา EJB, JSF และเทคโนโลยีเว็บในช่วงต้น) Java EE 6 นั้นง่ายมากทำงานร่วมกันได้ดีและฮาร์ดแวร์ในปัจจุบันทำงานได้อย่างราบรื่นดังนั้นเหตุผลดั้งเดิมที่กระตุ้นให้ Spring ใช้ไม่ได้อีกต่อไป
ฉันยังคงชอบฤดูใบไม้ผลิมากกว่า
และฉันจะส่งต่อ JSF ฉันคิดว่ามันเป็นเทคโนโลยีที่ตายแล้ว Spring MVC น่าจะเป็นทางเลือกที่ดีกว่า ก็ดิ้นเช่นกัน คิดในแง่ของสัญญาบริการ XML แรกและคุณสามารถแยกส่วนหลังออกจาก UI ได้อย่างสมบูรณ์
ฉันขอแนะนำ Spring + Tomcat เว้นแต่คุณจะรอเวลาให้ glassfish v3 และ Weld เป็นผู้ใหญ่มากขึ้น ขณะนี้มีปัญหาเล็กน้อยเกี่ยวกับการใช้หน่วยความจำ / การโหลด cpu เมื่อเรียกใช้ glassfish ด้วยแอปพลิเคชันที่เปิดใช้งาน CDI
ไม่ได้อ่านทุกอย่าง แต่เพียงเพื่อบอกว่าตอนนี้คุณสามารถใช้ EJB3 ในสงครามบน Java EE 6 เพื่อให้คุณสามารถใช้ EJB3 บน Tomcat ได้ (ฉันคิดว่า)
ฉันแนะนำให้คุณ Tomcat กับ Spring เนื่องจาก:
เป็นทางเลือกที่ดีในการเลือก Tomcat เนื่องจากคุณไม่ต้องการการประมวลผลที่มีน้ำหนักมาก