ORM เป็น Anti-Pattern หรือไม่ [ปิด]

ฉันมีการสนทนาที่กระตุ้นและขัดขวางมากกับเพื่อนร่วมงานเกี่ยวกับ ORM และข้อดีและข้อเสีย ในความคิดของฉัน ORM มีประโยชน์เฉพาะในกรณีที่หายาก อย่างน้อยในประสบการณ์ของฉัน

แต่ฉันไม่ต้องการแสดงข้อโต้แย้งของตัวเองในเวลานี้ ดังนั้นฉันถามคุณคุณคิดอย่างไรเกี่ยวกับออม? ข้อดีและข้อเสียคืออะไร?

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

• ที่ไม่ตรงกัน
  • แนวคิดเชิงวัตถุ
  • ความแตกต่างของชนิดข้อมูล
  • ความแตกต่างด้านโครงสร้างและความสมบูรณ์
  • ความแตกต่างที่บิดเบือน
  • ความแตกต่างของการทำธุรกรรม
• การแก้ปัญหาความต้านทานไม่ตรงกัน
  • ลด
  • สถาปัตยกรรมทางเลือก
  • ค่าตอบแทน
• การต่อสู้
• ความแตกต่างทางปรัชญา

ฉันคิดว่าถ้าคุณใช้เวลาในการอ่านบทความคุณจะเข้าใจว่าข้อเท็จจริงที่ว่า ORM บางครั้งถูกอธิบายว่าเป็นรูปแบบการต่อต้านนั้นแท้จริงแล้วหลีกเลี่ยงไม่ได้ โดเมนทั้งสองนั้นแตกต่างกันมากดังนั้นวิธีการใด ๆ ที่จะปฏิบัติต่อโดเมนหนึ่งเป็นอีกโดเมนหนึ่งเป็นค่าเริ่มต้นการต่อต้านรูปแบบในแง่ที่ว่ารูปแบบการต่อต้านเป็นรูปแบบที่ขัดต่อปรัชญาของโดเมน

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

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

นอกหลักสูตรเนื่องจากทุกอย่างมีประโยชน์ ORM มีแนวโน้มที่จะถูกละเมิด ถ้าคุณคิดว่ามันจะมาแทนที่ความต้องการที่จะรู้ทุกอย่างเกี่ยวกับฐานข้อมูลที่คุณทำงานอยู่มันจะกลับมากัดคุณ ยาก

ในที่สุดขอให้ฉันเสียบอีกหนึ่งคำตอบของฉันลงใน"รูปแบบ ActiveRecord ตาม / สนับสนุนหลักการออกแบบ SOLID หรือไม่" คำถามซึ่งสำหรับฉันเป็นคำถามที่เกี่ยวข้องมากกว่า "มันเป็นรูปแบบการต่อต้าน"

นี่คล้ายกับการถามว่า "สว่านไฟฟ้าเป็นแบบป้องกันหรือไม่" ORMs ได้รับตำแหน่งที่ดีในกล่องเครื่องมือของฉันลดรหัสต้นแบบและฉันยังสามารถใช้ SQL แบบกำหนดเองได้หากจำเป็น ดังนั้นถ้ามันเป็นรูปแบบการต่อต้านมันเป็นรูปแบบที่ต่อต้าน?

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

ฉันอยากจะเรียกบางอย่างว่า "anti-pattern" ซึ่งถูกเรียกเป็นครั้งแรกโดย Martin Fowler และตั้งแต่นั้นมาก็ถูกนำมาใช้ในภาษาการเขียนโปรแกรมสมัยใหม่เกือบทุกภาษา (ดูบทความ Wikipedia บน ActiveRecord )

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

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

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

ประสบการณ์ของฉัน: ฉันใช้ NHibernate กับ Linq2NHibernate

ข้อดี:

• มันกำจัด "Magic Strings" หรืออย่างน้อยก็มีสถานที่ที่ครั้งหนึ่งและครั้งเดียวที่จะนำพวกเขา
• มันช่วยให้ฉันทำงานในกระบวนทัศน์ของ OO ได้ตลอดเวลา
• รหัสอ่านง่ายกว่า
• รหัสที่อยู่ด้านบนนั้นเปลี่ยนได้ง่ายกว่า
• มันช่วยให้คุณสามารถแลกเปลี่ยนฐานข้อมูลเชิงสัมพันธ์ที่แท้จริงของคุณโดยไม่ต้องดูแลที่เก็บแยก 2 แห่ง (ทำไม่ค่อยบ่อยนัก แต่นั่นเป็นข้อดีอย่างหนึ่งถ้าคุณต้องการ)

จุดด้อย:

• รหัสยากที่จะเขียนเพราะ
• มันไม่ได้เป็นนามธรรมที่เพียงพอคุณยังต้องคุ้นเคยกับสิ่งที่กำลังทำอยู่เบื้องหลัง

ฉันจะบอกว่ามันไม่ได้ขึ้นอยู่กับสัญญาที่คนส่วนใหญ่หวังในตอนแรก ฉันจะไม่โทษใครบางคนที่บอกว่ามันเป็นรูปแบบต่อต้าน ฉันพบว่าในกรณีของฉันฉันยังต้องทำการทดสอบการรวมกับฐานข้อมูล SQLite เพื่อให้แน่ใจว่าการสืบค้น Linq2NHibernate ของฉันใช้งานได้จริง ดังนั้นหากคุณทำการทดสอบการรวมกับฐานข้อมูลเชิงสัมพันธ์จริง ๆ แล้วการกำจัดแบบนั้นจะช่วยขจัดปัญหาด้วย "สายอักขระเวทมนต์"

ถ้าฉันจะเริ่มโครงการใหม่ฉันไม่แน่ใจว่าฉันจะใช้ ORM หรือไม่ ฉันอาจจะ แต่ฉันไม่สามารถพูดได้ว่าคุณควร ฉันจะบอกว่ามันเหมือนกับความแตกต่างระหว่างการเลือก C ++ หรือ Java / .NET สำหรับโครงการของคุณ: คุณต้องการความยืดหยุ่นที่คุณได้รับจากการทำงานในระดับที่ต่ำกว่าหรือคุณต้องการทำงานในระดับที่สูงขึ้นและ (ควรจะมากกว่า) การผลิต? คำตอบปกติในการทำงานที่สูงของระดับที่คุณได้รับไปด้วย ซึ่งมักจะหมายถึงการใช้ ORM

จุดแข็งของ ORM คือช่วยให้คุณสร้างแบบจำลองพฤติกรรมการใช้งานโดยใช้เทคนิคเชิงวัตถุ ในโลกที่มีการวางแผนอย่างรอบคอบคุณมีแอพพลิเคชั่นหนึ่งชั้นที่ภาษาของธุรกิจตรงตามภาษาของทีมพัฒนา ORM เป็นตัวเปิดใช้งานของสิ่งนั้นถ้าใช้ ORM อย่างสมเหตุสมผล

จุดอ่อนคือจำนวนคนที่จริง ๆ แล้วการเขียนโปรแกรมเชิงวัตถุจริงๆมีขนาดค่อนข้างเล็ก ผู้คนจำนวนมากเขียนสปาเก็ตตี้และลูกชิ้นด้วยวัตถุที่มีการเชื่อมโยงกันสูงซึ่งมีพฤติกรรมเล็กน้อยของพวกเขาเองและพฤติกรรมจริง ๆ จบลงด้วยคลาส "Service" และ "Manager" ที่น่าเกลียด 8000 บรรทัดและรหัสนั้นมักจะสับสนจนทุกคนกลัว ของการเปลี่ยนแปลงเพราะพวกเขาไม่สามารถเข้าใจได้ว่าผลข้างเคียงจะเป็นอย่างไร

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

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

ORM จะไม่ทำให้คุณฉลาดขึ้น แต่อยู่ในมือของนักพัฒนาซอฟต์แวร์ที่เหมาะสมสามารถนำไปสู่รหัสที่รักษาได้และมีคุณภาพสูงขึ้น

บางทีคำตอบอาจอยู่ที่การตอบคำถามของคุณ: การจัดเก็บข้อมูลแอปพลิเคชันของคุณในสิ่งอื่นที่ไม่ใช่ฐานข้อมูลเชิงสัมพันธ์เป็นความคิดที่ดีหรือไม่? คุณกำลังขจัดปัญหาอะไรและคุณจะรับปัญหาอะไรอีก คุณสามารถอยู่ได้โดยปราศจากความสามารถในการอ้างอิงข้ามข้อมูลของคุณ (เชื่อมต่อ) ได้อย่างง่ายดายหรือกรองข้อมูลที่คุณต้องการได้อย่างรวดเร็วตามเกณฑ์หลายเกณฑ์หรือไม่ คุณไม่ต้องการการสนับสนุนการทำธุรกรรมที่มั่นคง (สมมติว่าทางเลือกของคุณไม่มี) ไม่ใช่ทุกแอปพลิเคชันที่จำเป็นต้องมีแหล่งข้อมูลที่สอดคล้องและสมบูรณ์เสมอ

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

ORM เป็นเครื่องมือ เช่นเดียวกับเครื่องมือทั้งหมดเมื่อใช้อย่างเหมาะสมพวกเขาทำงานได้ค่อนข้างดี เมื่อใช้อย่างไม่เหมาะสมจะต้องใช้ค้อนที่ใหญ่กว่าและเทปพันท่อ

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