ทำไมคุณจึงควรใช้ ORM? [ปิด]

114

ปิด . คำถามนี้เป็นคำถามความคิดเห็นตาม ขณะนี้ยังไม่ยอมรับคำตอบ

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

ปิดให้บริการใน7 ปีที่ผ่านมา

ปรับปรุงคำถามนี้

หากคุณมีแรงจูงใจใน "ข้อดี" ของ ORM และเหตุใดคุณจึงใช้ ORM ในการจัดการ / ลูกค้าเหตุผลเหล่านั้นคืออะไร?

พยายามเก็บเหตุผลเดียวต่อคำตอบเพื่อที่เราจะได้เห็นว่าข้อใดได้รับการโหวตให้เป็นเหตุผลที่ดีที่สุด

database orm

— Simon Munro
แหล่งที่มา

3

คุณควรทำให้เป็นวิกิพีเดียหากคุณต้องการแบบสำรวจ

— frankodwyer

+1 เพื่อทำให้เป็นวิกิหากคุณต้องการแบบสำรวจ

— cletus

16

แล้ว con's ล่ะ?

— Brian Matthews

4

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

— Piskvor ออกจากอาคาร

2

@ UğurGümüşhan, IMHO ประโยชน์หลักของการใช้ ORM คือการทำให้นักพัฒนามีประสิทธิผลมากขึ้นโดยให้พวกเขาเขียนโปรแกรมในภาษาเดียวกันและกระบวนทัศน์ OO ที่พวกเขาใช้ในแอปอื่น ๆ กระบวนงานที่เก็บไว้ไม่สามารถให้สิ่งนั้นได้เมื่อพวกเขาสร้างรหัสนักพัฒนาในภาษากระบวนงานที่เก็บไว้ RDBMS ดังนั้นพวกเขาจึงไม่สามารถทำทุกอย่างที่สามารถออม

— Bill Karwin

53

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

— บิลคาร์วิน
แหล่งที่มา

61

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

— troelskn

40

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

— Bill Karwin

2

ผู้ขายออกมาพร้อมกับเวอร์ชัน / คุณสมบัติใหม่ ๆ ตลอดเวลา ... เพียงแค่ต้องการคนเจ๋ง ๆ ในการเขียนภาษาถิ่นและอัปเกรดได้ง่าย!

— dotjoe

5

คำตอบที่ไร้ประโยชน์โดยทั่วไปฉันสงสัยว่าทำไมจึงถูกทำเครื่องหมายว่าเป็นคำตอบที่ดีดูเหมือนว่าผู้ชายที่ถามคำถามเพียงแค่พยายามให้เหตุผลกับเจ้านายของเขาว่าเขาควรใช้ ORM :) คำถามของฉันน่าจะเป็นปัญหาประเภทใดที่คุณจะพบกับ Hibernate stackoverflow.com/questions/6477170/…

— user310291

2

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

— Bill Karwin

83

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

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

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

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

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

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

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

โอ้ใช่นักพัฒนาบางคนคิดว่าการทำงานกับ ORM เป็นเรื่องสนุกดังนั้น ORM จึงเป็นสิ่งที่ดีจากมุมมองที่ทำให้นักพัฒนาของคุณมีความสุข =)

— เชย
แหล่งที่มา

1

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

— Doug Lampe

1

@ Doug - ฉันคิดว่าความแตกต่างที่ฉันได้รับคือ DAL แบบธรรมดาประกอบด้วย CRUD SQL ที่สร้างขึ้นเพียงเล็กน้อยในขณะที่ ORM มีสิ่งที่เป็นนามธรรมอื่น ๆ อีกมากมายเช่นคุณสมบัติการนำทางความคงอยู่ของการรวบรวมภาษาแบบสอบถามเฉพาะแคช ฯลฯ - วิธีที่ดีกว่า การระบุประเด็นของฉันในแง่ของการสังเกตของคุณอาจเป็นไปได้ว่าแม้ว่าการใช้คุณสมบัติอื่น ๆ ของ ORM จะช่วยให้คุณใช้งานได้เร็วขึ้น แต่ก็ไม่เป็นที่ยอมรับที่จะเพิกเฉยต่อการทำงานของคุณลักษณะเหล่านั้น บางทีอาจเป็นเพราะนามธรรมของ ORM รั่วไหลมากกว่าส่วนใหญ่ ( th.wikipedia.org/wiki/Leaky_abstraction )

— Chuck

โปรดอธิบายเพิ่มเติมเกี่ยวกับเรื่องนี้: "หากคุณไม่ได้ใช้คุณลักษณะการสืบค้นขั้นสูงของ ORM ของคุณมีตัวเลือกอื่น ๆ ที่ช่วยแก้ปัญหาที่เหลืออยู่" ในฐานะผู้สร้าง hibernate gavin king กล่าวว่า: "อันที่จริงระบบอย่าง Hibernate ได้รับการออกแบบโดยเจตนาให้เป็น" abstractions ที่รั่วไหล "เพื่อให้สามารถผสมใน SQL แบบเนทีฟได้อย่างง่ายดายเมื่อจำเป็นความรั่วของนามธรรม ORM เป็นคุณลักษณะไม่ใช่ข้อบกพร่อง !" - reddit.com/r/programming/comments/2cnw8x/…

— jungle_mole

1) นี่มันเก่าแล้ว ในตอนนั้น ORM มีคุณสมบัติทั้งหมด (แคชคิวรีแบตช์ ฯลฯ ) IMHO, การสืบค้นแบบอิงอ็อบเจ็กต์, โพลีมอร์ฟิกเป็นคุณสมบัติ ORM เดียวที่โค้ด gen (การแมป ADO อย่างชัดเจน) ไม่สามารถให้ได้อย่างง่ายดาย 2) แม้ว่าหลุมที่มีประโยชน์บางอย่างถูกทิ้งไว้โดยเจตนา แต่ก็มีความชั่วร้ายและคุณสมบัติขั้นสูงที่จำเป็นซึ่งสร้างช่วงการเรียนรู้ที่สูงใน ORM ดังนั้นคำตอบของฉันคือใช้ code gen แทน ORM เว้นแต่คุณต้องการการสืบค้นขั้นสูง *) เวลาปัจจุบันมีความหลากหลายเพียงพอใน ORM ที่คุณสมบัติที่เหมาะสมสำหรับทีมของคุณน่าจะอยู่ที่นั่น ตอนนี้ทีมของฉันชอบ Linq2DB

— Chuck

60

เร่งการพัฒนา ตัวอย่างเช่นการกำจัดโค้ดซ้ำ ๆ เช่นการแมปฟิลด์ผลลัพธ์คิวรีกับสมาชิกออบเจ็กต์และในทางกลับกัน

— บิลคาร์วิน
แหล่งที่มา

3

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

— Benjohn

@ Benjohn ฉันยอมรับว่าโซลูชัน ORM ถือว่าแต่ละแถวเป็นวัตถุในขณะที่ RDBMS ถือว่าชุดของแถวเป็นเอนทิตี มีหลายสิ่งที่คุณสามารถทำได้ในแนวความคิด RDBMS ที่คุณไม่สามารถทำได้ในแนวความคิด OO

— Bill Karwin

นี่ก็เหมือนกับการซื้อรถทั้งคันเพื่อใช้ท้ายรถมีหลายวิธีที่จะหลีกเลี่ยงการทำงานซ้ำซาก

— mohas

15

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

— บิลคาร์วิน
แหล่งที่มา

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

— Benjohn

1

@ เบ็นจอห์นฉันมักจะใส่กฎเกณฑ์ทางธุรกิจลงในฐานข้อมูล แต่กฎที่ซับซ้อนกว่านั้นไม่ได้เกิดขึ้นง่ายๆในข้อ จำกัด ที่เปิดเผย เช่น "ลูกค้าได้รับส่วนลด 10% สำหรับการสั่งซื้อทั้งหมดในครั้งแรกที่ซื้อกางเกงสแลคจากแบรนด์เดียวกันมากกว่าสามคู่" คุณจะใส่กฎทางธุรกิจนั้นลงในฐานข้อมูลได้อย่างไร (โปรดทราบว่าคำตอบเกี่ยวกับขั้นตอนการจัดเก็บนั้นเป็นเรื่องที่ยุ่งยาก)

— Bill Karwin

เป็นปี 2020 ฉันไม่เห็นใครใช้ขั้นตอนการจัดเก็บอีกต่อไป คุณชี้ยังยืนอยู่หรือไม่?

— ospider

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

— Bill Karwin

10

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

— บิลคาร์วิน
แหล่งที่มา

1

karwin.blogspot.com/2009/01/why-should-you-use-orm.html

— Andrew Breksa

8

คุณสามารถย้ายไปยังซอฟต์แวร์ฐานข้อมูลอื่นได้อย่างง่ายดายเนื่องจากคุณกำลังพัฒนาไปสู่นามธรรม

— Matt Fenelon
แหล่งที่มา

41

ใน 30 ปีบวกกับการทำงาน datbase ฉันไม่เคยต้องทำสิ่งนี้เลยสักครั้ง

— HLGEM

4

ไม่ได้หมายความว่าเป็นไปไม่ได้! :)

— Matt Fenelon

2

@HLGEM หมายความว่าคุณกำลังปิดตัวเลือกสำหรับลูกค้า มันอาจเกิดขึ้นได้ในเวลาเพียง 3 ปีของการทำงานของ webapps เราได้สร้างซอฟต์แวร์พกพาโดยใช้ ORMs

— Alfabravo

1

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

— Carlos Parraga

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

— jlh

4

เพื่อให้โมเดลวัตถุและโมเดลการคงอยู่ของคุณตรงกัน

— cletus
แหล่งที่มา

1

บางทีการคงอยู่ของคุณจะโปร่งใสกับแบบจำลองวัตถุของคุณ

— S.Lott

4

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

ตอนนี้ฉันกำลังใช้ ORM และมันช่วยเร่งพัฒนาการของฉัน

— curiousdork
แหล่งที่มา

3

เพื่อลดความซ้ำซ้อนของแบบสอบถาม SQL แบบธรรมดา

— ทิมวอร์เดิล
แหล่งที่มา

3

เหตุผลที่ฉันกำลังพิจารณาคือหลีกเลี่ยงโค้ดที่สร้างขึ้นจากเครื่องมือ DAL ของ VS2005 (การทำแผนที่สคีมา, TableAdapters)

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

ดูเหมือนว่าจะให้โซลูชันที่ใช้งานง่ายและสะอาดกว่าโซลูชัน DAL / BLL จากhttp://wwww.asp.net

ฉันกำลังคิดที่จะสร้างตัวสร้างโค้ด C # DAL ของคำสั่ง SQL ของตัวเอง แต่ ORM ดูเหมือนจะเป็นโซลูชันที่หรูหรากว่า

— แดนแมคเคลน
แหล่งที่มา

2

การรวบรวมและการทดสอบแบบสอบถาม

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

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

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

วันนี้มีความเกี่ยวข้องมากกว่าเมื่อไม่กี่ปีก่อนเมื่อคำถามถูกถาม แต่นั่นอาจเป็นกรณีของ Visual Studio และ Entity Framework เท่านั้นที่ประสบการณ์ของฉันอยู่ ปลั๊กอินสภาพแวดล้อมของคุณเองถ้าเป็นไปได้

— Chuck
แหล่งที่มา

1

คัดลอก sql ออกไป 95% ของเวลาดังนั้นทุกคนในทีมไม่จำเป็นต้องรู้วิธีการเขียนแบบสอบถามเฉพาะฐานข้อมูลที่มีประสิทธิภาพสูง

— Jared
แหล่งที่มา

1

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

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

— Anders Fjeldstad
แหล่งที่มา

0

ระดับ. net โดยใช้แม่แบบ code smith

http://nettiers.com/default.aspx?AspxAutoDetectCookieSupport=1

ทำไมโค้ดบางอย่างที่สามารถสร้างขึ้นได้เช่นกัน

— Jobo
แหล่งที่มา

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

— Judah Gabriel Himango

0

โน้มน้าวพวกเขาว่าคุณจะประหยัดเวลา / เงินเท่าใดเมื่อมีการเปลี่ยนแปลงเข้ามาและคุณไม่จำเป็นต้องเขียน SQL ของคุณใหม่เนื่องจากเครื่องมือ ORM จะทำสิ่งนั้นให้คุณ

— ZMF
แหล่งที่มา

0

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

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

ฉันเข้าใจว่าคำถามนั้นเป็นคำถามทั่วไป แต่แอพมือถือก็อยู่ในร่มทั่วไปเช่นกัน

— ไชเลนดราสิงห์ราชวัตร
แหล่งที่มา