Spring + Hibernate เลือกแทน EJB 3 หรือไม่

ฉันเข้าใจว่าเมื่อใดก็ตามที่โครงการ JEE ใหม่เริ่มต้นขึ้น (ซึ่งจะใช้เทคโนโลยีเหล่านี้) คนต้องการใช้การผสมผสานของ Spring + Hibernate แทนที่จะเป็น EJB 3

ดูเหมือนว่าผู้เขียนโปรแกรมรุ่นเยาว์จะได้รับคำแนะนำให้ทำเช่นนั้นแทนที่จะเป็น EJB

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

เฟรมเวิร์ก EJB 3+ นั้นค่อนข้างดีจริง ๆ เมื่อพวกเขามาพร้อมกับ JPA เป็นคำตอบสำหรับคำอธิบายประกอบที่กำหนดเฟรมเวิร์ก Persistence เช่นเดียวกับ CDI ซึ่งอนุญาตให้ใช้การเพิ่มการพึ่งพาคำอธิบายประกอบ คุณเพิ่มที่ด้านบนของ Weld นั้นด้วย ฤดูใบไม้ผลิในขณะนี้เป็นเพียงการติดตามในเกมที่มีการกำหนดค่าผ่านคำอธิบายประกอบ

ด้วยการกล่าวว่า backlack ประวัติศาสตร์กับ EJB1 และ 2 ไม่ควรถูกลดราคา พวกเขาไม่เพียง แต่ล้มเหลวในการแก้ปัญหาด้วยการเขียนแอปพลิเคชันระดับองค์กร แต่ล้มเหลวอย่างน่าทึ่ง มันเป็นความล้มเหลวอย่างสมบูรณ์ในส่วนของนักออกแบบเพื่อรับมือกับปัญหาที่แท้จริงที่นักพัฒนาองค์กรและผู้พัฒนาเว็บแอปพลิเคชันต้องเผชิญและส่งมอบโซลูชั่นที่พวกเขาต้องการจริงๆ

นอกจากนี้ความไม่ไว้วางใจที่เกิดขึ้นกับทิศทางของ Java ในปัจจุบันในเวลานี้และขาดความเชื่อมั่นในผู้ดูแลและเจ้าของ Sun JVM ใน Oracle ในปัจจุบัน หลายคนไม่เชื่อว่า Oracle จะพัฒนาบน Java และเป็นผู้นำในทิศทางนั้นและยังมีความกลัวว่า Apache Software Foundation อาจจะโยนเข้าไปในผ้าเช็ดตัว ผู้คนจำนวนมากกำลังมองหา OpenJDK สำหรับอนาคตของ Java แต่ก็ไม่ได้อยู่ในที่ที่จำเป็นสำหรับการปรับใช้องค์กร

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

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

EJB มีสัมภาระมากมาย ส่วนหนึ่งของสัมภาระนั้นมาจากความจริงที่ว่ามันเป็นเป้าหมายของผู้ชมที่ผิด อีกส่วนหนึ่งก็คือว่าทั้งสองรุ่นแรกเป็นอึมากที่สุด

หากคุณดูรุ่น EJB ดั้งเดิมการออกแบบก็คือนักพัฒนา EJB สามารถสร้างโซลูชันแบบแพคเกจที่สามารถใช้ได้ภายในคอนเทนเนอร์ที่สอดคล้องกับ EJB สำหรับร้านค้าในบ้านสิ่งที่เป็นนามธรรมในระดับนี้ไม่จำเป็น มันเป็นโซลูชั่นที่สมบูรณ์แบบในการสร้างตลาดที่เจริญรุ่งเรืองสำหรับผู้ขายส่วนประกอบ EJB บุคคลที่สาม อย่างไรก็ตามผู้ขาย Container นั้นคลั่งไคล้ในด้านการตลาดและทำให้การขายตันเป็นโซลูชั่นที่ทำงานได้สำหรับการพัฒนาทุกวัน นี่จะเทียบเท่ากับการสร้างรหัสแอปพลิเคชันของคุณทั้งหมดเป็นคอมโพเนนต์ COM +

สำหรับข้อมูลเพิ่มเติมเกี่ยวกับข้อมูลจำเพาะของ J2EE ดั้งเดิมผู้ขายส่วนใหญ่ที่เกี่ยวข้องมีเซิร์ฟเวอร์ CORBA และต้องการใช้ประโยชน์จากผลิตภัณฑ์เหล่านี้ในอนาคต ข้อมูลจำเพาะ EJB ถูกสร้างขึ้นบนโปรโตคอล IIOP (จริงๆแล้ว Java RMI ซึ่งเป็นชั้นบาง ๆ กว่า IIOP) CORBA ถูกปฏิเสธไปแล้วเนื่องจากความซับซ้อนของมันและ EJB เป็นเพียงการปลอมแปลง CORBA ดังนั้นมันจึงนำปัญหามากมายที่ CORBA มี ที่จริงแล้ว abstractions ของ EJB ทำให้ยากต่อการทำงานมากกว่าการใช้ CORBA อย่างแท้จริง

เมื่อยางกระทบพื้นผิวถนนคนก็ตระหนักว่าประสิทธิภาพของ EJB นั้นเลวร้าย ทุกการโทรเป็นการโทรทางไกลและความยากลำบากในการเริ่มต้นใช้งานแอปพลิเคชั่นและทำงานอย่างถูกต้องผู้คนจึงมองหาทางเลือกอื่นอย่างรวดเร็ว Hibernate และ Spring ที่ทำงานในคอนเทนเนอร์ JSP กลายเป็นโซลูชัน

EJB 3 "ประกาศใช้" วิธีนี้ แต่ก็ยังคงเป็นการประนีประนอมทั่วไปที่ไม่ได้ให้ประโยชน์มากนัก ยังไม่มีตลาดองค์ประกอบ EJB บุคคลที่สามดังนั้นจึงไม่มีประโยชน์ในการใช้คอนเทนเนอร์ EJB เพื่อสร้างโซลูชันของคุณ

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