ORM ยังเป็นแอนตีแพตเทิร์นอยู่หรือไม่?

 (github.com/getlago)
7 คะแนน โดย GN⁺ 2023-06-28 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ORM (Object-Relational Mapper) มักถูกวิจารณ์ว่าเป็นแอนตีแพตเทิร์นในการพัฒนาซอฟต์แวร์
  • อย่างไรก็ตาม คำวิจารณ์นี้ค่อนข้างเกินจริง และ ORM ก็ไม่ได้แย่โดยเนื้อแท้ เช่นเดียวกับเครื่องมือซอฟต์แวร์อื่นๆ
  • ปัญหาที่แท้จริงของ ORM มักเกิดจากการใช้งานผิดวิธีหรือความเข้าใจที่คลาดเคลื่อน
  • ORM และฐานข้อมูลเชิงสัมพันธ์ทำงานอยู่บนคนละกระบวนทัศน์ จึงอาจก่อให้เกิดความท้าทายด้านการทำ data modeling และความสัมพันธ์
  • ORM ละเมิดหลัก Single Responsibility Principle (SRP) และ Separation of Concerns (SOC) แต่คำวิจารณ์เหล่านี้ก็ไม่ใช่ปัญหาชี้ขาดเสมอไป
  • ปัญหาจริงของ ORM อยู่ที่ประสิทธิภาพและการมองเห็นภายในระบบ
  • หากใช้อย่างไม่ถูกต้อง ORM อาจไม่มีประสิทธิภาพ แต่ก็มีความสามารถในการปรับแต่งคิวรีและเพิ่มประสิทธิภาพได้
  • ปัญหา N+1 ที่ ORM ต้องไป-กลับกับฐานข้อมูลหลายครั้งสามารถบรรเทาได้ด้วยการใช้ data loader
  • ปัญหาใหญ่ที่สุดของ ORM คือเรื่องการมองเห็นและการดีบัก เพราะอาจไม่ให้ข้อความผิดพลาดที่ชัดเจน หรือทำให้เข้าใจและแก้ปัญหาได้ยาก
  • หากใช้อย่างถูกต้อง ORM ก็อาจมีประสิทธิภาพได้เทียบเท่า raw SQL แต่ผู้พัฒนาต้องใช้ฟีเจอร์ต่างๆ และแนวทางที่ใกล้เคียงกับ native SQL ให้เป็น
  • สำหรับคิวรีที่ซับซ้อนหรือมีปัญหาบางประเภท อาจจำเป็นต้องเปลี่ยนไปใช้คิวรีแบบ raw SQL
  • โดยรวมแล้ว ORM ไม่ได้แย่โดยเนื้อแท้ แต่จำเป็นต้องใช้อย่างระมัดระวังและมีความรู้เพื่อหลีกเลี่ยงปัญหาที่อาจเกิดขึ้น

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2023-06-28
ความเห็นจาก Hacker News
  • มีการวิจารณ์ข้อจำกัดและข้อเสียของ ORM เช่น การไม่สามารถใช้ฐานข้อมูลอื่นได้ และยังต้องมีความรู้เรื่อง SQL อยู่ดี
  • การสร้าง data layer ทีละหนึ่งคิวรีด้วย string interpolation และแนวทางที่ใกล้เคียงกับ raw JDBC ถูกมองว่าเป็นวิธีที่ดีกว่า
  • ORM มักจำกัดอยู่แค่การแมปตารางและวิวพื้นฐาน และมองข้ามความสามารถและฟีเจอร์ขั้นสูงของ SQL
  • ORM มีอยู่สองประเภท: แบบที่อิงจากโดเมนโมเดล และแบบที่สร้างโดเมนโมเดลจากฐานข้อมูลที่มีอยู่เดิม
  • ORM อย่าง jOOQ และ Hibernate มีการติดตั้งใช้งานและฟีเจอร์ที่หลากหลาย และถูกใช้เพื่อวัตถุประสงค์ที่ต่างกัน
  • ORM อาจมีประโยชน์ในแอปพลิเคชันที่ซับซ้อนซึ่งมีหลายตารางและมีความสัมพันธ์ foreign key ที่เหมาะสม
  • การใช้ raw SQL ใน string literal ถือเป็นทางเลือกหนึ่งแทน ORM และยังมีเครื่องมือที่ช่วยสร้าง query wrapper ให้ใช้ได้
  • ORM ที่เป็นเชิงปฏิบัติและไม่ได้พยายามซ่อนทุกอย่างไว้เป็นแพ็กเกจเดียว หรือไม่บังคับใช้ภาษา query ของตัวเอง มักได้รับความนิยมมากกว่า
  • SQLAlchemy ได้รับคำชมว่าเป็นแนวทางที่มอบ query layer ที่สะดวก โดยไม่พยายามสร้าง SQL ขึ้นมาใหม่
  • หากไม่ใช้ ORM นักพัฒนาจะต้องเขียนและดูแล database interface ของตัวเอง ซึ่งอาจทำให้เกิดบั๊กและช่องโหว่ด้านความปลอดภัยได้
  • คำวิจารณ์ที่ว่า ORM ขัดกับหลักการ SOLID ถูกมองว่าเป็นความขัดแย้งระหว่างคำสอนเชิงวิชาการกับการพัฒนาจริง
  • การขาดประสบการณ์หรือการได้รับอิทธิพลจากแนวปฏิบัติเชิงวิชาการมากเกินไป อาจทำให้เกิดปัญหาและงบประมาณบานปลายได้