ตั้งแต่ฤดูใบไม้ผลิคือสามารถที่จะใช้ทำธุรกรรมเช่นเดียวกับEJB สำหรับฉัน Spring สามารถทดแทนข้อกำหนดในการใช้ EJB ได้ ใครช่วยบอกฉันว่าข้อดีพิเศษของการใช้ EJB คืออะไร?
ตั้งแต่ฤดูใบไม้ผลิคือสามารถที่จะใช้ทำธุรกรรมเช่นเดียวกับEJB สำหรับฉัน Spring สามารถทดแทนข้อกำหนดในการใช้ EJB ได้ ใครช่วยบอกฉันว่าข้อดีพิเศษของการใช้ EJB คืออะไร?
คำตอบ:
Spring ได้รับการพัฒนาเป็นทางเลือกแทน EJB ตั้งแต่เริ่มต้นดังนั้นคำตอบคือคุณสามารถใช้ Spring แทน EJB ได้
หากมี "ข้อได้เปรียบ" ในการใช้ EJB ฉันว่ามันจะขึ้นอยู่กับทักษะของทีมของคุณ หากคุณไม่มีความเชี่ยวชาญเกี่ยวกับ Spring และมีประสบการณ์ EJB มากมายการใช้ EJB 3.0 ก็เป็นไปได้ดี
เซิร์ฟเวอร์แอปที่เขียนขึ้นเพื่อรองรับมาตรฐาน EJB ในทางทฤษฎีสามารถย้ายจากเซิร์ฟเวอร์แอป Java EE ที่เข้ากันได้ไปยังอีกเซิร์ฟเวอร์หนึ่ง แต่นั่นหมายถึงการอยู่ห่างจากส่วนขยายเฉพาะผู้ให้บริการทั้งหมดที่ล็อกคุณไว้กับผู้ให้บริการรายเดียว
สปริงพอร์ตระหว่างเซิร์ฟเวอร์แอปได้อย่างง่ายดาย (เช่น WebLogic, Tomcat, JBOSS ฯลฯ ) เนื่องจากไม่ได้ขึ้นอยู่กับเซิร์ฟเวอร์เหล่านี้
อย่างไรก็ตามคุณถูกล็อกเข้าสู่ฤดูใบไม้ผลิ
Spring สนับสนุนแนวทางปฏิบัติในการออกแบบ OO ที่ดี (เช่นอินเทอร์เฟซเลเยอร์การแยกข้อกังวล) ซึ่งเป็นประโยชน์ต่อปัญหาใด ๆ ที่พวกเขาสัมผัสแม้ว่าคุณจะตัดสินใจเปลี่ยนไปใช้ Guice หรือเฟรมเวิร์ก DI อื่น
อัปเดต: คำถามและคำตอบนี้มีอายุห้าปีในปี 2014 ต้องบอกว่าโลกของการเขียนโปรแกรมและการพัฒนาแอปพลิเคชันได้เปลี่ยนแปลงไปอย่างมากในช่วงเวลานั้น
ไม่ใช่แค่ตัวเลือกระหว่าง Java หรือ C #, Spring หรือ EJB อีกต่อไป ด้วยvert.xคุณสามารถละทิ้ง Java EE ได้ทั้งหมด คุณสามารถเขียนแอปพลิเคชันหลายภาษาที่ปรับขนาดได้สูงโดยไม่ต้องมีเซิร์ฟเวอร์แอป
อัปเดต: ตอนนี้เป็นเดือนมีนาคม 2016 Spring Boot นำเสนอวิธีที่ดียิ่งขึ้นในการเขียนแอปพลิเคชันโดยไม่ใช้เซิร์ฟเวอร์แอป Java EE คุณสามารถสร้าง JAR ที่ปฏิบัติการได้และรันบน JVM
ฉันสงสัยว่า Oracle จะยังคงสนับสนุนข้อมูลจำเพาะ Java EE หรือไม่ บริการทางเว็บได้เข้าครอบครอง EJB โซลูชัน EJB ตายแล้ว (แค่ความคิดเห็นของฉัน)
ก่อนอื่นให้ฉันพูดให้ชัดเจนฉันไม่ได้บอกว่าคุณไม่ควรใช้ Spring แต่เนื่องจากคุณกำลังขอข้อดีบางอย่างนี่คืออย่างน้อยสองข้อ:
EJB 3 เป็นมาตรฐานในขณะที่ Spring ไม่ใช่ (เป็นมาตรฐานโดยพฤตินัย แต่นั่นไม่ใช่สิ่งเดียวกัน) และสิ่งนี้จะไม่เปลี่ยนแปลงในอนาคตอันใกล้ แม้ว่าคุณจะสามารถใช้ Spring framework กับแอปพลิเคชันเซิร์ฟเวอร์ใดก็ได้ แต่แอปพลิเคชัน Spring จะถูกล็อกทั้งใน Spring เองและบริการเฉพาะที่คุณเลือกที่จะรวมเข้ากับ Spring
Spring framework อยู่ด้านบนของแอ็พพลิเคชันเซิร์ฟเวอร์และไลบรารีบริการ รหัสรวมบริการ (เช่นเทมเพลตการเข้าถึงข้อมูล) อยู่ในกรอบงานและเปิดเผยต่อผู้พัฒนาแอปพลิเคชัน ในทางตรงกันข้ามเฟรมเวิร์ก EJB 3 ถูกรวมเข้ากับแอ็พพลิเคชันเซิร์ฟเวอร์และโค้ดการรวมบริการจะถูกห่อหุ้มไว้ด้านหลัง ผู้จำหน่าย EJB 3 สามารถเพิ่มประสิทธิภาพและประสบการณ์ของนักพัฒนาโดยการทำงานในระดับแอปพลิเคชันเซิร์ฟเวอร์ ตัวอย่างเช่นพวกเขาสามารถผูกเอ็นจิน JPA กับการจัดการธุรกรรม JTA ได้อย่างใกล้ชิด อีกตัวอย่างหนึ่งคือการสนับสนุนการทำคลัสเตอร์ซึ่งโปร่งใสสำหรับนักพัฒนา EJB 3
แม้ว่า EJB 3 จะไม่สมบูรณ์แบบ แต่ก็ยังขาดคุณสมบัติบางอย่าง (เช่นการฉีดส่วนประกอบที่ไม่ได้รับการจัดการเช่น POJO แบบธรรมดา)
คะแนนของปาสคาลใช้ได้ อย่างไรก็ตามมีสิ่งต่อไปนี้สำหรับฤดูใบไม้ผลิ
ข้อกำหนด EJB นั้นค่อนข้างหลวมดังนั้นจึงสามารถสังเกตพฤติกรรมที่แตกต่างกันได้กับเซิร์ฟเวอร์แอปพลิเคชันที่แตกต่างกัน สิ่งนี้จะไม่เป็นความจริงในกรณีส่วนใหญ่แน่นอน แต่ฉันมีปัญหาเช่นนี้สำหรับ "มุมมืด"
Spring มีสินค้าพิเศษมากมายเช่นการทดสอบสปริง, AOP, MVC, การผสานรวม JSF เป็นต้น EJB มีบางส่วน (เช่น interceptors) แต่ในความคิดของฉันพวกเขายังไม่พัฒนามากนัก
สรุปแล้วขึ้นอยู่กับกรณีของคุณเป็นหลัก
EJBContainer.createEJBContainer()
API มาตรฐานสำหรับใช้คอนเทนเนอร์แบบฝัง ดังนั้นคำพูดของคุณก็ไม่ถูกต้อง
สปริงมีไว้เพื่อเสริม EJB ไม่ใช่เพื่อแทนที่ สปริงเป็นชั้นที่อยู่ด้านบนของ EJB อย่างที่เราทราบกันดีว่าการเข้ารหัส EJB นั้นทำได้โดยใช้ API ซึ่งหมายความว่าเราต้องใช้ทุกอย่างใน API โดยใช้ Spring framework เราสามารถสร้างรหัสแผ่นหม้อต้มจากนั้นก็เอาจานนั้นใส่ของลงไปแล้วทุกอย่างก็เสร็จ Spring ภายในเชื่อมต่อกับ EJB - Spring จะไม่มีอยู่หากไม่มี EJB
ข้อได้เปรียบหลักของการใช้ Spring คือไม่มีการมีเพศสัมพันธ์เลยระหว่างคลาส