Java ORM ใดที่คุณชอบและเพราะอะไร [ปิด]

มันเป็นคำถามที่เปิดกว้าง ฉันจะเริ่มต้นโครงการใหม่และกำลังมองหา ORM ที่แตกต่างกันเพื่อรวมเข้ากับการเข้าถึงฐานข้อมูล

คุณมีรายการโปรดหรือไม่? มีผู้ใดแนะนำให้คุณพักอย่างชัดเจน?

ฉันหยุดใช้ ORM แล้ว

เหตุผลไม่ได้เป็นข้อบกพร่องที่ดีในแนวคิด ไฮเบอร์เนตทำงานได้ดี แต่ฉันพบว่าแบบสอบถามมีค่าใช้จ่ายต่ำและฉันสามารถใส่ตรรกะที่ซับซ้อนจำนวนมากให้เป็นแบบสอบถาม SQL ขนาดใหญ่ได้และเปลี่ยนการประมวลผลจำนวนมากของฉันไปยังฐานข้อมูล

ดังนั้นให้พิจารณาใช้แพ็คเกจ JDBC

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

ORM จำนวนมากนั้นยอดเยี่ยมคุณต้องรู้ว่าทำไมคุณจึงต้องการเพิ่มสิ่งที่เป็นนามธรรมลงไปด้านบนของ JDBC ฉันสามารถแนะนำhttp://www.jooq.orgให้กับคุณ (ข้อจำกัดความรับผิดชอบ: ฉันเป็นผู้สร้าง jOOQ ดังนั้นคำตอบนี้จึงมีอคติ) jOOQ รวบรวมกระบวนทัศน์ต่อไปนี้:

• SQL เป็นสิ่งที่ดี หลายสิ่งหลายอย่างสามารถแสดงได้ค่อนข้างดีใน SQL ไม่จำเป็นต้องมีการลดลงของ SQL ที่สมบูรณ์
• แบบจำลองข้อมูลเชิงสัมพันธ์เป็นสิ่งที่ดี มันได้พิสูจน์รูปแบบข้อมูลที่ดีที่สุดในช่วง 40 ปีที่ผ่านมา ไม่จำเป็นสำหรับฐานข้อมูล XML หรือโมเดลข้อมูลเชิงวัตถุอย่างแท้จริง บริษัท ของคุณใช้ Oracle, MySQL, MSSQL, DB2 หรือ RDBMS อื่นแทน
• SQL มีโครงสร้างและไวยากรณ์ ไม่ควรแสดงโดยใช้การต่อสตริง "ระดับต่ำ" ใน JDBC - หรือการเชื่อมต่อสตริง "ระดับสูง" ใน HQL ซึ่งทั้งคู่มีแนวโน้มที่จะมีข้อผิดพลาดทางไวยากรณ์
• การรวมตัวแปรมีแนวโน้มที่จะซับซ้อนมากเมื่อจัดการกับคิวรีที่สำคัญ นั่นคือสิ่งที่ควรจะเป็นนามธรรม
• POJO นั้นยอดเยี่ยมเมื่อเขียนโค้ด Java ที่จัดการข้อมูลฐานข้อมูล
• POJO เป็นความเจ็บปวดในการเขียนและบำรุงรักษาด้วยตนเอง การสร้างรหัสเป็นวิธีที่จะไป คุณจะมีการสืบค้นที่ปลอดภัยรวมถึงการรวบรวมข้อมูลประเภท
• ฐานข้อมูลมาก่อน ในขณะที่แอปพลิเคชันด้านบนของฐานข้อมูลของคุณอาจมีการเปลี่ยนแปลงเมื่อเวลาผ่านไปฐานข้อมูลอาจจะคงอยู่นานกว่าเดิม
• ใช่คุณมีขั้นตอนการจัดเก็บและประเภทที่ผู้ใช้กำหนด (UDT) ในฐานข้อมูลดั้งเดิมของคุณ เครื่องมือฐานข้อมูลของคุณควรสนับสนุน

มี ORM ที่ดีอื่น ๆ อีกมากมาย โดยเฉพาะอย่างยิ่งไฮเบอร์เนตหรือ iBATIS มีชุมชนที่ยอดเยี่ยม แต่ถ้าคุณกำลังมองหาสิ่งที่เข้าใจง่ายและเรียบง่ายฉันจะบอกว่าลอง jOOQ คุณจะรักมัน! :-)

ลองดูตัวอย่าง SQL นี้:

  // Select authors with books that are sold out
  SELECT * 
    FROM T_AUTHOR a
   WHERE EXISTS (SELECT 1
                   FROM T_BOOK
                  WHERE T_BOOK.STATUS = 'SOLD OUT'
                    AND T_BOOK.AUTHOR_ID = a.ID);

และวิธีสามารถแสดงใน jOOQ:

  // Alias the author table
  TAuthor a = T_AUTHOR.as("a");

  // Use the aliased table in the select statement
  create.selectFrom(a)
        .whereExists(create.selectOne()
                           .from(T_BOOK)
                           .where(T_BOOK.STATUS.equal(TBookStatus.SOLD_OUT)
                           .and(T_BOOK.AUTHOR_ID.equal(a.ID))))));

Hibernate เนื่องจากเป็นมาตรฐาน defacto ใน Java และเป็นหนึ่งในแรงผลักดันในการสร้าง JPA มันได้รับการสนับสนุนอย่างยอดเยี่ยมใน Spring และเกือบทุก Java framework รองรับ ในที่สุด GORM นั้นเป็นเสื้อคลุมที่เท่ห์มาก ๆ รอบตัวมันทำการค้นหาแบบไดนามิกและใช้ Groovy

มันถูกส่งไปยัง. NET (NHibernate) ด้วยซ้ำดังนั้นคุณจึงสามารถใช้งานได้ที่นั่นเช่นกัน

ไฮเบอร์เนตเพราะ:

• เสถียร - อยู่ใกล้มาหลายปีแล้วมันไม่มีปัญหาอะไรเลย
• กำหนดมาตรฐานในฟิลด์ ORM
• ใช้มาตรฐาน (JPA) นอกเหนือจากการกำหนด
• มีข้อมูลมากมายเกี่ยวกับมันบนอินเทอร์เน็ต มีแบบฝึกหัดมากมายการแก้ปัญหาที่พบบ่อย ฯลฯ
• มีประสิทธิภาพ - คุณสามารถแปลโมเดลวัตถุที่ซับซ้อนมากเป็นโมเดลเชิงสัมพันธ์ได้
• มีการสนับสนุน RDBMS หลักและขนาดกลางใด ๆ
• ใช้งานง่ายเมื่อคุณเรียนรู้ได้ดี

จุดสองสามข้อเกี่ยวกับสาเหตุที่ (และเมื่อ) ใช้ ORM:

• คุณทำงานกับวัตถุในระบบของคุณ (หากระบบของคุณได้รับการออกแบบมาอย่างดี) แม้ว่าการใช้ JDBC คุณจะสร้างเลเยอร์การแปลเพื่อให้คุณถ่ายโอนข้อมูลของคุณไปยังวัตถุของคุณ แต่การเดิมพันของฉันคือการจำศีลดีกว่าการแปลมากกว่าโซลูชันที่กำหนดเองใด ๆ
• มันไม่ได้กีดกันคุณในการควบคุม คุณสามารถควบคุมสิ่งต่าง ๆ ในรายละเอียดเล็ก ๆ น้อย ๆ และถ้า API ไม่มีคุณสมบัติระยะไกล - ดำเนินการแบบสอบถามท้องถิ่นและคุณมีมัน
• ระบบขนาดกลางหรือใหญ่กว่าไม่สามารถมีคิวรีได้หนึ่งตัน (ไม่ว่าจะอยู่ที่ใดที่หนึ่งหรือกระจายอยู่ทั่ว) ถ้ามันมีจุดมุ่งหมายที่จะรักษาได้
• ถ้าประสิทธิภาพไม่สำคัญ Hibernate เพิ่มค่าใช้จ่ายด้านประสิทธิภาพซึ่งในบางกรณีไม่สามารถเพิกเฉยได้

ฉันจะแนะนำให้ใช้MyBatis มันเป็นเลเยอร์บางที่ด้านบนของ JDBC มันง่ายมากที่จะแมปออบเจ็กต์กับตารางและยังคงใช้ SQL ธรรมดาทุกอย่างอยู่ภายใต้การควบคุมของคุณ

ฉันมีประสบการณ์ที่ดีกับAvaje Ebeanเมื่อฉันกำลังเขียนแอปพลิเคชัน JavaSE ขนาดกลาง

โดยใช้การเพิ่มความคิดเห็น JPA มาตรฐานเพื่อกำหนดเอนทิตี แต่จะเปิดเผย API ที่ง่ายกว่ามาก (ไม่มีเอนทิตีผู้จัดการหรือเอนทิตีใด ๆ ที่แนบมา / ต่อพ่วง) นอกจากนี้ยังช่วยให้คุณสามารถใช้เคียวรี SQL หรือการโทร JDBC ธรรมดาเหตุการณ์ได้อย่างง่ายดายเมื่อจำเป็น

นอกจากนี้ยังมี API ที่ปลอดภัยและเป็นประเภทที่ปลอดภัยสำหรับการสืบค้น คุณสามารถเขียนสิ่งต่าง ๆ เช่น:

List<Person> boys = Ebean.find(Person.class)
                                  .where()
                                       .eq("gender", "M")
                                       .le("age", 18)
                                  .orderBy("firstName")
                                  .findList();

SimpleORMเพราะมันตรงไปตรงมาและไม่มีเวทย์มนตร์ มันกำหนดโครงสร้างข้อมูลเมตาทั้งหมดในรหัส Java และมีความยืดหยุ่นมาก

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

แต่แตกต่างจาก Hibernate SimpleORM ใช้โครงสร้างวัตถุและสถาปัตยกรรมที่ง่ายมากที่หลีกเลี่ยงความจำเป็นในการแยกวิเคราะห์ที่ซับซ้อนการประมวลผลรหัสไบต์เป็นต้น SimpleORM มีขนาดเล็กและโปร่งใสบรรจุในสองขวดขนาด 79K และ 52K เพียงขนาดเล็ก การพึ่งพา (Slf4j) (ไฮเบอร์เนตมีมากกว่า 2400K บวกกับ Jars ที่ขึ้นต่อกันประมาณ 2000K) ซึ่งทำให้ SimpleORM ง่ายต่อการเข้าใจและลดความเสี่ยงด้านเทคนิคลงอย่างมาก

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

โอ้และ Eclipse Link ได้รับเลือกให้ใช้งานการอ้างอิงสำหรับ JPA 2.0

ในขณะที่ฉันแบ่งปันข้อกังวลเกี่ยวกับการแทนที่ Java สำหรับการสืบค้น SQL ในรูปแบบอิสระฉันคิดว่าคนที่วิจารณ์ ORM กำลังทำเช่นนั้นเนื่องจากการออกแบบแอปพลิเคชันที่ไม่ดี

True OOD ถูกขับเคลื่อนโดยคลาสและความสัมพันธ์และ ORM ให้การแมปที่สอดคล้องกันของประเภทความสัมพันธ์และวัตถุต่าง ๆ หากคุณใช้เครื่องมือ ORM และสิ้นสุดการเข้ารหัสแบบสอบถามนิพจน์ในภาษาแบบสอบถามใด ๆ กรอบ ORM สนับสนุน (รวมถึง แต่ไม่ จำกัด เฉพาะต้นไม้นิพจน์ Java, วิธีการสืบค้น, OQL และอื่น ๆ ) คุณกำลังทำสิ่งผิดปกติเช่นโมเดลชั้นเรียนของคุณ ส่วนใหญ่แล้วไม่รองรับความต้องการของคุณในแบบที่ควรจะเป็น การออกแบบแอปพลิเคชันใหม่ทั้งหมดไม่ต้องการการสืบค้นในระดับแอปพลิเคชัน ฉันได้รับการรีแฟคเตอร์หลายโครงการที่ผู้คนเริ่มใช้เฟรมเวิร์ก ORM ในลักษณะเดียวกับที่ใช้ในการฝังค่าคงที่สตริง SQL ในรหัสของพวกเขาและในที่สุดทุกคนก็แปลกใจว่าแอพพลิเคชั่นทั้งหมดนั้นง่ายเพียงใด อัพโมเดลคลาสของคุณด้วยโมเดลการใช้งาน ได้รับสำหรับสิ่งต่าง ๆ เช่นฟังก์ชั่นการค้นหา ฯลฯ คุณต้องใช้ภาษาของคิวรี แต่ถึงอย่างนั้นเคียวรีก็มีข้อ จำกัด อย่างมากที่การสร้าง VIEW และการแมปที่ซับซ้อนยิ่งขึ้นไปยังคลาสถาวรแบบอ่านอย่างเดียวนั้นดีกว่า ในภาษาคิวรีบางภาษาในรหัสของแอปพลิเคชันของคุณ วิธีการ VIEW ยังใช้ประโยชน์จากความสามารถของฐานข้อมูลและ Materialization นั้นสามารถใช้งานได้ดีกว่า SQL ที่เขียนด้วยมือในแหล่ง Java ของคุณ ดังนั้นฉันไม่เห็นเหตุผลใด ๆ สำหรับแอปพลิเคชันที่ไม่สำคัญไม่ใช้ ORM แต่ถึงอย่างนั้นเคียวรีก็มีข้อ จำกัด อย่างมากที่การสร้าง VIEW ที่ซับซ้อนและการแมปที่คลาสถาวรแบบอ่านอย่างเดียวนั้นดีกว่าการรักษาและดูมากกว่าการสร้างนิพจน์ในภาษาคิวรีบางรหัสในแอปพลิเคชันของคุณ วิธีการ VIEW ยังใช้ประโยชน์จากความสามารถของฐานข้อมูลและ Materialization นั้นสามารถใช้งานได้ดีกว่า SQL ที่เขียนด้วยมือในแหล่ง Java ของคุณ ดังนั้นฉันไม่เห็นเหตุผลใด ๆ สำหรับแอปพลิเคชันที่ไม่สำคัญไม่ใช้ ORM แต่ถึงอย่างนั้นเคียวรีก็มีข้อ จำกัด อย่างมากที่การสร้าง VIEW ที่ซับซ้อนและการแมปที่คลาสถาวรแบบอ่านอย่างเดียวนั้นดีกว่าการรักษาและดูมากกว่าการสร้างนิพจน์ในภาษาคิวรีบางรหัสในแอปพลิเคชันของคุณ วิธีการ VIEW ยังใช้ประโยชน์จากความสามารถของฐานข้อมูลและ Materialization นั้นสามารถใช้งานได้ดีกว่า SQL ที่เขียนด้วยมือในแหล่ง Java ของคุณ ดังนั้นฉันไม่เห็นเหตุผลใด ๆ สำหรับแอปพลิเคชันที่ไม่สำคัญไม่ใช้ ORM