มีเหตุผลที่ดีที่จะไม่ใช้ ORM หรือไม่? [ปิด]

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

อย่างไรก็ตามฉันไม่เข้าใจเหตุผลหลักสองประการที่ไม่ใช้ NHibernate หรือโครงการที่คล้ายกัน:

1. เราสามารถสร้างอ็อบเจ็กต์การเข้าถึงข้อมูลของตัวเองด้วยคิวรี SQL และคัดลอกแบบสอบถามเหล่านั้นออกจาก Microsoft SQL Server Management Studio
2. การดีบัก ORM อาจเป็นเรื่องยาก

ดังนั้นแน่นอนว่าฉันสามารถสร้างชั้นการเข้าถึงข้อมูลของฉันด้วยจำนวนมากSELECTฯลฯ แต่ที่นี่ฉันพลาดข้อได้เปรียบของการรวมอัตโนมัติคลาสพร็อกซีที่โหลดขี้เกียจและความพยายามในการบำรุงรักษาที่ต่ำกว่าหากตารางได้รับคอลัมน์ใหม่หรือคอลัมน์ได้รับ เปลี่ยนชื่อ (การอัปเดตจำนวนมากSELECT, INSERTและUPDATEคำสั่งกับการอัปเดตการตั้งค่าการทำแผนที่และอาจ refactoring เรียนธุรกิจและ DTOs.)

นอกจากนี้การใช้ NHibernate คุณสามารถประสบปัญหาที่คาดไม่ถึงหากคุณไม่รู้จักกรอบงานเป็นอย่างดี ตัวอย่างเช่นเชื่อมั่น Table.hbm.xml ที่คุณตั้งค่าความยาวของสตริงให้ตรวจสอบโดยอัตโนมัติ อย่างไรก็ตามฉันยังสามารถจินตนาการถึงจุดบกพร่องที่คล้ายกันในชั้นการเข้าถึงข้อมูลแบบ "ง่ายๆ" SqlConnection

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

(ฉันควรจะเพิ่มว่าฉันคิดว่านี่เป็นเหมือนแอปพลิเคชันที่ใช้“ ใหญ่”. NET / C # ตัวแรกซึ่งจะต้องมีการทำงานเป็นทีมแนวทางปฏิบัติที่ดีซึ่งถูกมองว่าเป็นเรื่องปกติใน Stack Overflow เช่นการทดสอบหน่วยหรือการผสานรวมอย่างต่อเนื่องนั้นไม่ใช่ - มีอยู่ที่นี่จนถึงปัจจุบัน)

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

เหตุใด ORM จึงทำให้การดีบักยากขึ้น คุณจะได้รับผลลัพธ์เดียวกันไม่ว่าจะมาจาก proc ที่จัดเก็บไว้หรือจาก ORM

ฉันเดาว่าความเสียหายที่แท้จริงเพียงอย่างเดียวที่ฉันคิดได้ด้วย ORM คือรูปแบบการรักษาความปลอดภัยมีความยืดหยุ่นน้อยกว่าเล็กน้อย

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

คำตอบสั้น ๆ คือใช่มีเหตุผลที่ดีจริงๆ ตามความเป็นจริงมีหลายกรณีที่คุณไม่สามารถใช้ ORM ได้

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

จุดหวานของออมส์

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

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

ฉันได้เห็นแนวทางเดิมใช้ได้ผลดีกับโครงการ J2EE ที่มีขนาดใหญ่มาก (100 ปี)

ในกรณีที่ ORM อาจไม่เหมาะสมที่สุด

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

• ในแอปพลิเคชันที่มีฐานรหัสเดิมจำนวนมากของกระบวนงานที่เก็บไว้คุณอาจต้องการใช้ชั้นการเข้าถึงข้อมูลที่มุ่งเน้นการทำงาน (เพื่อไม่ให้สับสนกับภาษาที่ใช้งานได้) เพื่อห่อหุ้ม sprocs ที่เป็นหน้าที่ สิ่งนี้จะใช้เลเยอร์การเข้าถึงข้อมูลและการออกแบบฐานข้อมูลที่มีอยู่ (และผ่านการทดสอบและแก้ไขแล้ว) ซึ่งมักแสดงถึงความพยายามในการพัฒนาและทดสอบที่ค่อนข้างมากและช่วยประหยัดในการย้ายข้อมูลไปยังรูปแบบฐานข้อมูลใหม่ มักจะเป็นวิธีที่ดีในการตัดเลเยอร์ Java รอบฐานรหัส PL / SQL แบบเดิมหรือกำหนดเป้าหมายแอป VB, Powerbuilder หรือ Delphi ไคลเอนต์ใหม่ด้วยเว็บอินเตอร์เฟส

• รูปแบบคือตำแหน่งที่คุณรับช่วงโมเดลข้อมูลที่ไม่จำเป็นต้องเหมาะสมกับการแมปหรือการแมป หาก (ตัวอย่าง) คุณกำลังเขียนอินเทอร์เฟซที่เติมหรือดึงข้อมูลจากอินเทอร์เฟซต่างประเทศคุณอาจจะไม่ต้องทำงานกับฐานข้อมูล

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

• แอปพลิเคชันประสิทธิภาพสูงที่คุณต้องการปรับแต่งการเข้าถึงฐานข้อมูลของคุณ ในกรณีนี้อาจนิยมทำงานในระดับที่ต่ำกว่า

• สถานการณ์ที่คุณใช้กลไกการเข้าถึงข้อมูลที่มีหน้าที่เช่น ADO.Net ที่ 'ดีเพียงพอ' และการเล่นอย่างดีกับแพลตฟอร์มนั้นมีประโยชน์มากกว่าที่ ORM นำมา

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

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

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

1. ทดสอบรหัสของคุณ
2. การรักษารหัสของคุณ

วิธีแก้ปัญหาเหล่านี้คือ:

1. ทำให้โค้ดของคุณสามารถทดสอบได้ (โดยใช้หลักการSOLID )
2. เขียนการทดสอบอัตโนมัติสำหรับโค้ดให้มากที่สุด
3. ทำการทดสอบอัตโนมัติให้บ่อยที่สุด

เมื่อมาถึงคำถามของคุณการคัดค้านทั้งสองรายการที่คุณระบุดูเหมือนจะไม่รู้มากกว่าสิ่งอื่นใด

ไม่สามารถเขียนแบบสอบถาม SELECT ด้วยมือ (ซึ่งฉันคิดว่าเป็นสาเหตุที่ต้องคัดลอกวาง) ดูเหมือนจะบ่งบอกว่ามีความจำเป็นเร่งด่วนสำหรับการฝึกอบรม SQL บางอย่าง

มีสองเหตุผลที่ฉันไม่ใช้ ORM:

1. ห้ามปฏิบัติตามนโยบายของ บริษัท โดยเด็ดขาด (ซึ่งในกรณีนี้ฉันจะไปทำงานที่อื่น)
2. โครงการนี้มีข้อมูลที่เข้มข้นมากและการใช้โซลูชันเฉพาะของผู้ขาย (เช่น BulkInsert) มีเหตุผลมากกว่า

ข้อโต้แย้งตามปกติเกี่ยวกับ ORM (โดยเฉพาะอย่างยิ่ง NHibernate) ได้แก่ :

1. ความเร็ว

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

2. ความซับซ้อน

   สำหรับความซับซ้อนการใช้ ORM หมายถึงรหัสน้อยซึ่งโดยทั่วไปหมายถึงความซับซ้อนน้อย หลายคนที่ใช้การเข้าถึงข้อมูลที่เขียนด้วยมือ (หรือสร้างรหัส) พบว่าตัวเองกำลังเขียนกรอบของตนเองบนไลบรารีการเข้าถึงข้อมูล "ระดับต่ำ" (เช่นการเขียนวิธีการช่วยเหลือสำหรับ ADO.Net) สิ่งเหล่านี้ถือได้ว่ามีความซับซ้อนมากขึ้นและที่แย่กว่านั้นคือไม่ค่อยมีการจัดทำเป็นเอกสารหรือผ่านการทดสอบมาอย่างดี
   หากคุณกำลังมองหา NHibernate โดยเฉพาะเครื่องมือเช่น Fluent NHibernate และ Linq To NHibernate จะทำให้เส้นโค้งการเรียนรู้อ่อนลง

สิ่งที่ทำให้ฉันเกี่ยวกับการอภิปราย ORM ทั้งหมดก็คือคนกลุ่มเดียวกันที่อ้างว่าการใช้ ORM จะยาก / ช้าเกินไป / อะไรก็ตามที่เป็นคนกลุ่มเดียวกันที่มีความสุขมากกว่าการใช้ Linq To Sql หรือ Typed Datasets ในขณะที่ Linq To Sql เป็นก้าวสำคัญในทิศทางที่ถูกต้อง แต่ก็ยังคงเป็นเวลาหลายปีที่ผ่านมาซึ่ง ORM โอเพนซอร์สบางส่วนอยู่ อย่างไรก็ตามเฟรมเวิร์กสำหรับทั้ง Typed Datasets และ Linq To Sql นั้นยังคงซับซ้อนอย่างมหาศาลและการใช้เฟรมเวิร์กสำหรับ (Table = Class) + (CRUD พื้นฐาน) มากเกินไปนั้นยากมาก

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

(เป็นอย่างไรบ้างสำหรับการพูดจาโผงผาง?)

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

จุดแข็งอย่างหนึ่งของ Hibernate คือคุณสามารถพูดสิ่งต่างๆได้ 3 ครั้งเท่านั้น: ทุกคุณสมบัติจะถูกกล่าวถึงในชั้นเรียนไฟล์. hbm.xml และฐานข้อมูล ด้วยการสืบค้น SQL คุณสมบัติของคุณจะอยู่ในคลาสฐานข้อมูลคำสั่งที่เลือกคำสั่งแทรกคำสั่งการอัปเดตคำสั่งการลบและรหัสการจัดเรียงและ unmarshalling ทั้งหมดที่รองรับการสืบค้น SQL ของคุณ! สิ่งนี้จะยุ่งได้อย่างรวดเร็ว ในทางกลับกันคุณรู้ว่ามันทำงานอย่างไร คุณสามารถแก้ไขข้อบกพร่องได้ ทุกอย่างอยู่ในชั้นการคงอยู่ของคุณเองไม่ได้ฝังอยู่ในบาดาลของเครื่องมือของบุคคลที่สาม

Hibernate อาจเป็นลูกหลานของ Spolsky's Law of Leaky Abstractions หลีกเลี่ยงเส้นทางที่ถูกตีเล็กน้อยและคุณจำเป็นต้องรู้ลึกถึงการทำงานภายในของเครื่องมือ อาจเป็นเรื่องที่น่ารำคาญมากเมื่อคุณรู้ว่าคุณสามารถแก้ไข SQL ได้ในไม่กี่นาที แต่คุณกลับใช้เวลาหลายชั่วโมงในการพยายามดึงเครื่องมือ dang ของคุณไปสู่การสร้าง SQL ที่สมเหตุสมผล การแก้จุดบกพร่องบางครั้งอาจเป็นฝันร้าย แต่ก็ยากที่จะโน้มน้าวผู้คนที่ไม่เคยไปที่นั่น

แก้ไข: คุณอาจต้องการตรวจสอบ iBatis.NET หากพวกเขาจะไม่หันกลับมาเกี่ยวกับ NHibernate และพวกเขาต้องการควบคุมการสืบค้น SQL ของพวกเขา

แก้ไข 2: นี่คือธงสีแดงขนาดใหญ่แม้ว่า: "แนวทางปฏิบัติที่ดีซึ่งเห็นได้ว่าเป็นเรื่องปกติใน Stack Overflow เช่นการทดสอบหน่วยหรือการผสานรวมอย่างต่อเนื่องจะยังไม่ปรากฏในตอนนี้" ดังนั้นนักพัฒนาที่ "มีประสบการณ์" เหล่านี้พวกเขามีประสบการณ์ในการพัฒนาอะไรบ้าง? ความมั่นคงในงานของพวกเขา? ดูเหมือนว่าคุณอาจอยู่ท่ามกลางผู้คนที่ไม่ได้สนใจงานด้านนี้เป็นพิเศษดังนั้นอย่าปล่อยให้พวกเขาทำลายความสนใจของคุณ คุณต้องมีความสมดุล ทะเลาะกัน.

ฉันทำงานในโครงการหนึ่งที่ไม่ได้ใช้ ORM ก็ประสบความสำเร็จอย่างมาก มันเป็นโครงการที่

1. ต้องมีการปรับขนาดในแนวนอนตั้งแต่เริ่มต้น
2. จะต้องมีการพัฒนาอย่างรวดเร็ว
3. มีรูปแบบโดเมนที่ค่อนข้างเรียบง่าย

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

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

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

ฉันพบว่าเมื่อออกแบบระบบที่มีข้อกำหนดด้านประสิทธิภาพที่หนักหน่วงฉันมักจะถูกท้าทายให้ค้นหาวิธีที่จะทำให้ระบบมีประสิทธิภาพมากขึ้น หลายครั้งฉันลงเอยด้วยโซลูชันที่มีโปรไฟล์ประสิทธิภาพการเขียนจำนวนมาก (หมายความว่าเรากำลังเขียนข้อมูลมากกว่าที่เรากำลังอ่านข้อมูลอยู่มาก) ในกรณีเหล่านี้ฉันต้องการใช้ประโยชน์จากสิ่งอำนวยความสะดวกที่แพลตฟอร์มฐานข้อมูลมอบให้ฉันเพื่อให้บรรลุเป้าหมายประสิทธิภาพของเรา (คือ OLTP ไม่ใช่ OLAP) ดังนั้นถ้าฉันใช้ SQL Server และฉันรู้ว่าฉันมีข้อมูลมากมายที่จะเขียนทำไมฉันไม่ใช้การแทรกจำนวนมาก ... เช่นเดียวกับที่คุณค้นพบแล้ว ORMS ส่วนใหญ่ (ฉันไม่รู้ว่า แม้แต่ชิ้นเดียวก็ทำ) ไม่มีความสามารถในการใช้ประโยชน์จากข้อได้เปรียบเฉพาะของแพลตฟอร์มเช่นเม็ดมีดจำนวนมาก

คุณควรรู้ว่าคุณสามารถผสมผสานเทคนิค ORM และ Non-ORM ได้ ฉันเพิ่งพบว่ามีกรณีพิเศษจำนวนหนึ่งที่ ORM ไม่สามารถรองรับความต้องการของคุณได้และคุณต้องแก้ไขปัญหาเหล่านี้สำหรับกรณีเหล่านั้น

เมื่อคุณต้องการอัปเดต 50000000 ระเบียน ตั้งธงหรืออะไรก็ตาม

ลองทำสิ่งนี้โดยใช้ ORM โดยไม่ต้องเรียกใช้กระบวนงานที่เก็บไว้หรือคำสั่ง SQL ดั้งเดิม ..

อัปเดต 1: ลองดึงข้อมูลหนึ่งระเบียนที่มีเพียงไม่กี่ฟิลด์ (เมื่อคุณมีโต๊ะ "กว้าง" มาก) หรือผลสเกลาร์ ออมก็ดูดที่นี่ด้วย

อัปเดต 2 : ดูเหมือนว่า EF 5.0 เบต้าจะสัญญาการอัปเดตเป็นกลุ่ม แต่นี่เป็นข่าวที่ร้อนแรงมาก (2012, มกราคม)

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

คุณสมบัตินอกเหนือ:

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

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

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

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

อย่าปล่อยให้ประสบการณ์ของสมาชิกในทีมอาวุโสของคุณลากคุณไปในทิศทางตรงกันข้ามกับวิวัฒนาการของวิทยาศาสตร์คอมพิวเตอร์ ฉันได้รับการพัฒนาอย่างมืออาชีพมา 23 ปีและหนึ่งในค่าคงที่คือการดูถูกคนใหม่โดยโรงเรียนเก่า ORM เป็นภาษา SQL เหมือนภาษา C ที่ใช้ในการประกอบและคุณสามารถเดิมพันได้ว่าเทียบเท่ากับ C ++ และ C # กำลังมาถึง รหัสโรงเรียนใหม่หนึ่งบรรทัดเท่ากับ 20 บรรทัดของโรงเรียนเก่า

ฉันคิดว่าบางทีเมื่อคุณทำงานกับระบบที่ใหญ่ขึ้นคุณสามารถใช้เครื่องมือสร้างโค้ดเช่น CodeSmith แทน ORM ... ฉันเพิ่งพบสิ่งนี้: Cooperator Frameworkซึ่งสร้าง SQL Server Stored Procedures และยังสร้างเอนทิตีธุรกิจตัวทำแผนที่เกตเวย์ lazyload และทุกสิ่งใน C # ... ลองดู ... มันเขียนโดยทีมงานที่นี่ในอาร์เจนตินา ...

ฉันคิดว่ามันอยู่ตรงกลางระหว่างการเข้ารหัสเลเยอร์การเข้าถึงข้อมูลทั้งหมดและใช้ ORM ...

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

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

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

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

หากเป็นฐานข้อมูล OLAP (เช่นข้อมูลคงที่ข้อมูลแบบอ่านอย่างเดียวที่ใช้สำหรับการรายงาน / การวิเคราะห์ ฯลฯ ) การใช้กรอบงาน ORM จะไม่เหมาะสม แทนที่จะใช้ฟังก์ชันการเข้าถึงข้อมูลดั้งเดิมของฐานข้อมูลเช่นกระบวนงานที่เก็บไว้จะดีกว่า ORM เหมาะกว่าสำหรับระบบทรานแซคชัน (OLTP)

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

ฉันเป็นนักพัฒนามืออาชีพมา 10 ปีเป็นผู้นำโครงการมูลค่ากว่าล้านดอลลาร์ที่ประสบความสำเร็จมากมายและฉันไม่เคยเขียนแอปพลิเคชันที่จำเป็นเพื่อให้สามารถเปลี่ยนไปใช้ฐานข้อมูลใด ๆ ได้เลย ทำไมคุณถึงต้องการให้ลูกค้าทำเช่นนี้? วางแผนอย่างรอบคอบเลือกฐานข้อมูลที่เหมาะสมสำหรับสิ่งที่คุณต้องการและยึดติดกับมัน ส่วนตัว SQL Server สามารถทำอะไรก็ได้ที่ฉันต้องการ ง่ายและได้ผลดี มีแม้แต่รุ่นฟรีที่รองรับข้อมูลสูงสุด 10GB โอ้และมันใช้งานได้ดีกับ. NET

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

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

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

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

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

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

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

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

ฉันขอแนะนำให้อ่านนี้สำหรับรายการข้อเสียของ ORM

http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx

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

/ แอสเกอร์

ประสบการณ์ที่ฉันเคยมีกับ Hibernate คือความหมายของมันนั้นละเอียดอ่อนและเมื่อมีปัญหาก็ยากที่จะเข้าใจว่าเกิดอะไรขึ้นภายใต้ประทุน ฉันได้ยินจากเพื่อนคนหนึ่งว่ามักจะเริ่มต้นด้วย Criteria จากนั้นต้องการความยืดหยุ่นเพิ่มขึ้นเล็กน้อยและต้องการ HQL และหลังจากนั้นสังเกตว่าต้องใช้ SQL ดิบ (เช่น Hibernate ไม่มีสหภาพ AFAIK)

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

ในการใช้ ORM ควรเข้าใจอย่างแท้จริง น่าเสียดายที่คน ๆ หนึ่งรู้สึกว่ามันง่ายในขณะที่มันไม่ใช่

ไม่ใช่เพื่อเป็นคำตอบฉันต้องการเรียบเรียงคำพูดที่ฉันได้ยินเมื่อเร็ว ๆ นี้ "ORM ที่ดีก็เหมือนเยติทุกคนพูดถึง แต่ไม่มีใครเห็น"

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

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

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

ไม่มีอาร์กิวเมนต์สำหรับ # 1 เนื่องจากการคัดลอกและวางคิวรีและการเข้ารหัสในข้อความไม่ให้ความยืดหยุ่นและสำหรับ # 2 orm ส่วนใหญ่จะตัดข้อยกเว้นเดิมจะอนุญาตให้ติดตามการสืบค้นที่สร้างขึ้นเป็นต้นดังนั้นการดีบักจึงไม่ใช่วิทยาศาสตร์จรวดเช่นกัน

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

การเขียนกรอบของคุณเองอาจเป็นเรื่องยากและมักจะพลาดไป

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

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

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

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

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

มิฉะนั้นจะตกนรกด้วย ORMs ตอนนี้ฉันถือว่าพวกเขาเป็นแฟชั่น