โครงการพัฒนาเว็บประเภทใดที่ได้รับประโยชน์จากการใช้ ORM


10

ฉันจะเริ่มด้วยการบอกว่าฉันได้ทำฐานข้อมูลของฉัน 95% โดยใช้ SQL เมื่อเร็ว ๆ นี้ฉันได้ทำการตรวจสอบ ORM ต่างๆเช่น NHibernate และ Doctrine

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

เนื่องจากฉันรู้สึกสะดวกสบายในการเขียน SQL และเห็นได้ชัดว่าไม่ได้ตระหนักถึงประโยชน์ที่ได้รับการสอนบ่อยครั้งในการใช้ ORM คำถามของฉันสำหรับผู้ใช้ ORM ที่หนักหน่วงคือ:

โครงการพัฒนาเว็บประเภทใดที่ได้รับประโยชน์สูงสุดจากการใช้ ORM


3
คำตอบคือ "ทั้งหมดนี้" แต่นั่นอาจไม่ใช่สิ่งที่คุณต้องการรู้ คุณอาจต้องการปรับแต่งคำถามของคุณเพื่อถามข้อมูลเฉพาะเพิ่มเติม
S.Lott

1
สำหรับฉันแล้ว SQL นั้นง่ายต่อการผลิต แต่นั่นเป็นเพราะการปรับตัวให้ชินกับสภาพแวดล้อมของฉัน ฉันอ่านว่า ORM ไม่ใช่ตัวเลือกที่ดีที่สุดเสมอไปเพราะช้ากว่า SQL ปกติ อย่างไรก็ตามนักพัฒนาซอฟต์แวร์หลายคนระบุว่านี่ไม่ใช่เรื่องสำคัญ ฉันส่วนใหญ่อยากรู้เกี่ยวกับโครงการที่เหมาะสมที่สุดสำหรับออม ฉันเห็นคำตอบส่วนใหญ่น่าจะเป็น "ทั้งหมด" และนั่นก็ใช้ได้เช่นกัน ฉันไม่ต้องการคำตอบที่เฉพาะเจาะจง :)
Fred Wilson

หากคุณไม่ขอรายละเอียดเพิ่มเติมคุณจะไม่ได้เรียนรู้อะไรมากมาย
S.Lott

คำตอบ:


5

(เกือบ)แอปพลิเคชันทั้งหมดได้รับประโยชน์จาก ORM

ครั้งแรกที่ผมไม่เห็นด้วยกับข้อได้เปรียบคุณรายการสำหรับการออม

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

แทนผลประโยชน์ที่แท้จริงของการออมคือ:

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

ในขณะที่คุณแสดงความคิดเห็นด้านหนึ่งของ ORM คือการสูญเสียประสิทธิภาพ อย่างไรก็ตามสิ่งนี้สามารถชดเชยได้ด้วยการใช้ฮาร์ดแวร์มากขึ้น

โดยทั่วไปเวลาโปรแกรมเมอร์นั้นแพงกว่าฮาร์ดแวร์ดังนั้น ORM จึงเป็นตัวเลือกที่ดีแทนที่จะเป็น SQL แบบเข้ารหัสด้วยมือ

ORM นั้นดีที่สุดสำหรับ applciations ที่มีตรรกะฐานข้อมูล CRUD ที่ค่อนข้างง่าย ORM มีประสิทธิภาพน้อยกว่าสำหรับ :

  • แอปพลิเคชันที่ต้องการการเข้าถึงฐานข้อมูลน้อย / ไม่มาก
  • แอปพลิเคชันที่ส่วนใหญ่ขึ้นอยู่กับแบบสอบถามที่ซับซ้อนและตรรกะ CRUD ง่าย ๆ
  • สถานการณ์ที่ประสิทธิภาพมีความสำคัญ แต่ไม่สามารถปรับใช้ฮาร์ดแวร์ได้เร็วขึ้น

จากประสบการณ์ของฉันสถานการณ์เหล่านี้หายาก ดังนั้นคำตอบของฉัน


"การใช้ ORM ไม่ได้แปลว่าคุณไม่จำเป็นต้องรู้จัก SQL" - จริง ข้อดีอย่างหนึ่งที่ฉันเห็นในสภาพแวดล้อมของทีมคือเราสามารถมุ่งเน้นชุดทักษะ SQL เพื่อไม่ให้นักพัฒนาทุกคนที่ทำงานในชั้นธุรกิจต้องเป็นผู้เชี่ยวชาญ
Fred Wilson

1
สำหรับการสืบค้นที่ซับซ้อนคุณสามารถย้อนกลับไปใช้ SQL และเขียนแบบสอบถาม SQL ได้เสมอ
harsimranb

4

ฉันก็เขียน SQL ได้อย่างสบายเช่นกัน ฉันยังรู้สึกสะดวกสบายมากขึ้นโดยไม่ต้องเขียน SQL ใด ๆ เลยรวมถึงไม่ต้องกังวลเกี่ยวกับการเชื่อมต่อการตัดการเชื่อมต่อการรวมกำไร ฯลฯ ไปยังฐานข้อมูล

ดังนั้น .. ฉันจะตอบเชิงลบของคำถามของคุณ โครงการพัฒนาเว็บไซต์เดียวที่ไม่ได้รับประโยชน์จาก ORM เป็นโครงการที่ไม่ได้พูดคุยกับฐานข้อมูลเลย ซึ่งฉันเชื่อว่าเป็นชนกลุ่มน้อย (ถ้ามี)


+1: ฉันคิดว่าตัวเองมีความเชี่ยวชาญเป็นอย่างมากที่ sql แต่ยังคงต้องการ OR / M ในความเป็นจริงฉันจะบอกว่าคุณจำเป็นต้องมีการจัดการกับ sql เพื่อใช้ประโยชน์จาก OR / M อย่างอื่นเมื่อการรั่วไหลของนามธรรมคุณจะไม่พบปัญหา "ไม่ต้องการรู้ SQL มาก" ไม่ใช่คุณสมบัติ สำหรับฉันมันคือทั้งหมดที่เกี่ยวกับการเพิ่มผลผลิตและการมีคอมไพเลอร์พบปัญหาไม่ใช่รันไทม์และ OR / M (โดยเฉพาะ generics / linq รุ่นใหม่ที่มีพื้นฐานดีมาก)
Brook

@Brook - ฉันเห็นด้วยอย่างสุดใจ การใช้ OR / M ไม่ได้หมายความว่าความรู้ SQL นั้นเป็นทางเลือก
OtávioDécio

2

ขึ้นอยู่กับประสบการณ์ของฉันกับ ASP.NET WebForms ฉันจะเสนอว่าโครงการเว็บโดยใช้statefulกรอบเว็บไม่ได้รับประโยชน์สูงสุดจากการใช้ออม

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

คุณเรียงลำดับนามธรรมห่างจากจุดสิ้นสุดของท่อส่ง (HTML output) และเป็นธรรมชาติที่เชิญชวนให้จัดการจุดเริ่มต้น (แหล่งข้อมูล) ในลักษณะเดียวกันเพื่อให้คุณอยู่ในตรรกะทางธุรกิจของคุณในรหัสแอปพลิเคชันเท่านั้น

ไม่ใช่ว่าฉันไม่ได้บอกว่านี่เป็นวิธีที่ดีในการทำสิ่งต่าง ๆ มันเป็นเพียงที่ ORM เหมาะกับธรรมชาติ


2

ในแอปพลิเคชันที่คุณมีโมเดลวัตถุขนาดใหญ่และเชื่อมต่อกัน ORM จะช่วยให้คุณประหยัดจากการเขียนตัวเชื่อมเดียวกันซ้ำแล้วซ้ำอีก

ข้อดีอีกอย่างคือการโหลดแบบสันหลังยาวซึ่งคุณต้องการให้ api ส่งคืนกราฟวัตถุที่ลูกค้าของ api จะใช้ชุดย่อยของกราฟนั้นเท่านั้น


1

ผมเชื่อว่าคุณมีความสับสนออมกับ DBAL

แนวคิดที่คุณอ้างถึงคือ Database Abstraction Layer (DBAL) ซึ่งช่วยให้คุณเขียน "sql" แบบพกพาซึ่งไม่ได้ขึ้นอยู่กับระบบฐานข้อมูลพื้นฐาน

ORM บนมืออื่น ๆ (ซึ่งเป็น (เกือบ?) มักจะสร้างอยู่ด้านบนของ DBAL):

Object-relational mapping (ORM, O/RM, and O/R mapping) in computer software is a programming technique for converting data between incompatible type systems in object-oriented programming languages. This creates, in effect, a "virtual object database" that can be used from within the programming language. (วิกิพีเดีย)

กล่าวง่ายๆคือ ORM ช่วยให้คุณสามารถแปลงข้อมูลจากฐานข้อมูลแบบเรียบเป็นตัวแทนวัตถุที่พองตัว


ขอบคุณสำหรับการชี้แจง เหตุผลหลักสำหรับฉันที่จะย้ายไปที่ ORM คือการมุ่งเน้นที่ OOP และย้ายออกจากการเขียน SQL มากขึ้นถ้ามันเหมาะสมสำหรับบางโครงการ
Fred Wilson

1

โครงการที่ไม่ได้รับประโยชน์จาก ORM จะเป็น:

  • คนที่ไม่ได้มุ่งเน้นวัตถุ;
  • อันที่ไม่จำเป็นต้องเก็บข้อมูล;
  • อันที่ใช้ DB เชิงวัตถุจึงไม่ต้องการชั้นการทำแผนที่เพิ่มเติม
  • อันที่ใช้โซลูชัน NoSQL ที่ไม่มีความสัมพันธ์
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.