อะไรคือข้อโต้แย้งกับการใช้ EntityFramework? [ปิด]

31

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

ความกังวลหลักของฉันคือ:

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

ข้อโต้แย้งสำหรับ EF คือ:

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

สถาปัตยกรรมปัจจุบันของเราประกอบด้วยบริการ WPF ซึ่งจัดการการเรียกฐานข้อมูลผ่านขั้นตอนการจัดเก็บพารามิเตอร์, วัตถุ POCO ที่ไปที่ / จากบริการ WCF และไคลเอนต์ WPF และไคลเอนต์ WPF เดสก์ท็อปของตัวเองซึ่งเปลี่ยน POCOs เป็นแบบจำลองชั้นเรียน DataBinding

ดังนั้นคำถามของฉันคือ EF เหมาะสมกับสิ่งนี้หรือไม่ มีข้อผิดพลาดใด ๆ เกี่ยวกับ EF ที่ฉันไม่ทราบหรือไม่?

architecture orm entity-framework

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

ลองดูสิ .. การเปรียบเทียบประสิทธิภาพและการรองรับ LINQ: ormeter.net

— M.Sameer

7

ฉันเพิ่งประเมิน Entity Framework และสถานที่ที่ดีที่สุดที่ฉันพบสำหรับปัญหาและฟีเจอร์ที่ขาดหายไปคือ: http://data.uservoice.com/forums/72025-ado-net-entity-framework-ef-feature-suggestions

รายการที่มีคะแนนโหวตมากที่สุด:

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

มีปัญหาอื่น ๆ อีกมากมายในรายการ User Voice

ในหมายเหตุด้านข้างฉันตื่นเต้นเป็นอย่างมากเกี่ยวกับการเปิดตัว EF 4.1 ซึ่งจะรวมถึงวิธีการใช้รหัสเป็นครั้งแรก ... http://blogs.msdn.com/b/adonet/archive/2011/03/15/ef-4 -1-ปล่อยผู้สมัคร available.aspx

นี่อาจผลักดันให้ฉันลองใช้ EF ในแอปพลิเคชั่นการผลิต

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

การโต้แย้งกับ: วันที่ 1 และ 2 และ 3: มันช้า !!! มีเส้นโค้งการเรียนรู้ (จำเป็นต้องรู้วิธีการเข้าร่วมซ้าย - ใช้เวลา 3 ชั่วโมงในการหาวิธีการทำเพื่อให้คนอื่นจะรู้ว่าสิ่งที่กำลังทำ ... ), เพจใน LINQ แทน SQL (เช่น feches milion 10 แถวจากนั้นรับ 20 แถวจากออฟเซ็ตโดยพลการแล้วคุณสงสัยว่าทำไมมันถึงช้าขนาดนั้น) ... Repo ไม่ปลอดภัยโดยใช้ดอกยางคุณต้องเริ่มต้นมันต่อการสอบถามและการเริ่มต้น repo คือ ช้ามาก (เช่น 5 วินาที) หากคุณมีฐานข้อมูลที่ใหญ่กว่า (นั่นหมายถึง 100-200 ตารางไม่ใช่ขนาดใหญ่จริงๆ)

— แน่ใจ

2

@Quandary ดูเหมือนว่าคุณกำลังดำเนินการ IQueryables (เช่นการโทร.ToList()หรือ.ToArray) ก่อนที่นิพจน์ LINQ ของคุณจะถูกกำหนดอย่างสมบูรณ์ นั่นเป็นเหตุผลที่มันดึงระเบียนทั้งหมดและทำให้ช้าลง

— orad

6

การทำแบบสาขาต่อข้อผิดพลาด / คุณสมบัติกับ EF สามารถเจ็บปวดอย่างน่าทึ่งในเวลาผสาน ลองนึกภาพว่าสองสาขา A และ B ทำการเปลี่ยนแปลงกับฐานข้อมูล (ซึ่งอาจจะเกิดขึ้นมากมายในช่วงแรกของโครงการใหม่)

คุณรวมไฟล์ "ปกติ" ทั้งหมด - ไฟล์ cs ฯลฯ จากนั้นก็ถึงเวลาที่จะผสาน Model.edmx และทันใดนั้นคุณไม่เพียงแค่ผสานการแมปโลจิคัลระหว่างโมเดลวัตถุและฐานข้อมูลของคุณ แต่ยังรวมถึงตำแหน่งของตารางในไดอะแกรมเอนทิตี

การผสาน Model.edmx นั้นเจ็บปวดมากจนเรายอมรับวิธีที่น่ารังเกียจพอสมควร:

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

— Frank Shearar
แหล่งที่มา

1

คำวิจารณ์นี้ไม่สามารถใช้ได้กับ EF Code First แต่ใช้ได้กับ Model First และ Database First

— Alan Macdonald

ฉันสร้างการแมปทั้งหมดด้วยตนเองโดยใช้ Fluent และควบคุมการทำแผนที่ทั้งหมด สิ่งเหล่านี้อยู่ภายในไฟล์. cs แยกต่างหาก

— Steven Ryssaert

5

EF มีข้อดีอีกสองอย่างที่คุณขาดไป:

คุณสามารถมี Entity span tables
คุณสามารถแบ่งตารางออกเป็นหลายประเภทของเอนทิตี
คุณสามารถสร้างเอนทิตีจากฐานข้อมูล (เช่นฐานข้อมูลเป็นวิธีการหลัก)
คุณสามารถสร้างฐานข้อมูลจากเอนทิตี (เช่นรหัสเป็นวิธีการหลัก)
ข้อความค้นหา LINQ จะถูกแปลเป็นข้อความค้นหา SQL เพื่อปรับปรุงประสิทธิภาพ

ข้อเสีย (โดยเฉพาะถ้าคุณใช้การตรวจสอบ):

คุณต้องสร้างแอตทริบิวต์ [MetadataClass] ที่ชี้ไปยังคลาสอื่นที่มีคุณสมบัติที่คุณต้องการตรวจสอบกับแอตทริบิวต์การตรวจสอบที่เหมาะสม คุณสมบัติทั้งหมดเป็นobjectประเภทดังนั้นจึงมีเพียงเพื่ออ่านข้อมูลเมตา ยังคงมีรหัสที่ไม่ใช้งานเป็นจำนวนมาก
การใช้ EntityFramework เป็นแนวคิดที่แตกต่างจากวิธีที่ NHibernate (และเวอร์ชั่น Java หลักของผู้ปกครอง) ออกแบบมาให้ทำงาน EntityFramework ทำงานได้ดีที่สุดในโหมดที่แนบซึ่งวัตถุนั้นใช้การเชื่อมต่อแบบสดตลอดเวลา เครื่องมือ ORM แบบ NHibernate และคล้ายคลึงกันทำงานได้ดีที่สุดในโหมดเดี่ยวซึ่งการเชื่อมต่อจะใช้เมื่อโหลด / บันทึกข้อมูลเท่านั้น

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

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

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

— Berin Loritsch
แหล่งที่มา

รหัสที่คุณเรียกว่าเป็นวิธีการหลักเรียกว่ารหัสอย่างเป็นทางการ

— Robert Koritnik

1

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

— RationalGeek

1

โดยแนบผมหมายถึงการโต้ตอบของคุณทั้งหมดที่มีวัตถุที่จะต้องเกิดขึ้นภายในusing(EFConnection conn = new EFConnection)สร้าง หากคุณพยายามซ่อนวัตถุนั้นไว้ที่ใดที่หนึ่งเพื่อความปลอดภัยเพื่อให้คุณสามารถทำการอัปเดตอย่างรวดเร็วและบันทึกอีกครั้งในusing(...)คำสั่งที่สองคุณจะต้องคิดอีกครั้ง ดูmsdn.microsoft.com/en-us/library/bb896271.aspxและmsdn.microsoft.com/en-us/library/bb896248.aspx การใช้ EF 3.5 (ซึ่งฉันต้องใช้กับเวอร์ชั่นล่าสุด) นั้นไม่ได้สะอาดเลย

— Berin Loritsch

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

— RationalGeek

2

นี่ไม่เป็นความจริง. EF มีแนวคิดที่แข็งแกร่งเกี่ยวกับหน่วยงานเดี่ยว เอนทิตีที่ดึงออกมาต้องถูกแนบกับบริบทก่อนจึงจะสามารถดำเนินการตามบริบทได้ (เช่นการอัปเดตในฐานข้อมูล) นอกจากนี้คลาสเมทาดาทาก็มีความจำเป็นเฉพาะถ้า EF สร้างเอนทิตีของคุณให้คุณ POCOs, IMO เป็นวิธีที่ดีกว่ามากในการใช้ EF การใช้ POCO ทำให้การทดสอบง่ายขึ้นมากโดยเฉพาะ

— Matt Greer

2

สิ่งหนึ่งที่ Microsoft ไม่ดีมากคือความเข้ากัน~~ได้แบบ~~ย้อนกลับโดยเฉพาะเมื่อพูดถึงเทคโนโลยีใหม่

โดยเฉพาะ EF1 (.net 3.5) แตกต่างจาก EF4 (.net 4.0) มาก - อาจเกิดขึ้นกับรุ่นถัดไป

ฉันจะรอสักครู่และดูว่าเทคโนโลยีเติบโตขึ้นอย่างไร

ในช่วงเวลาดังกล่าวให้ลองใช้ nHibernate - มันไม่เทียบเท่า แต่มันจะโตเต็มที่และถูกใช้อย่างดุเดือด

— Ophir Yoktan
แหล่งที่มา

1

ง่ายๆ ... รูปแบบโดเมนนั้นเป็นแบบจำลองเชิงสัมพันธ์ในฐานข้อมูลของคุณ ดังนั้นการแมปตารางบางอย่างกับชั้นเรียนและโยนมันลงบนเส้นลวดเป็นเพียงความเกียจคร้านธรรมดา ตารางอาจแมปโลคัลเป็น 1 วัตถุแม้ว่าฐานข้อมูลจะเป็น 3 ตารางที่แตกต่างกัน ออกแบบฐานข้อมูลอย่างชาญฉลาด
สิ่งที่ 2 ของ EF นี้ไม่สามารถสร้างแบบสอบถามที่แน่นอนและคุณต้องเขียนต่อไป
3rd รูปแบบโดเมนไม่ได้แมปโดยตรงไปยังบริการ .. หนึ่งจะต้องการผลักดันชุดข้อมูลที่น้อยที่สุดผ่านสายเป็น DTO .. โดยเฉพาะอย่างยิ่งถ้ามันจะมีการสื่อสารกับแอพมือถือ
5 ความสามารถในการทดสอบ ... ไม่สามารถสร้างการทดสอบที่ละเอียดพอที่จะให้การถดถอยที่เพียงพอกับการเปลี่ยนแปลงรหัส ... ทั้งหมดเพื่อง่ายต่อการ
ทำลาย ...

ฉันสามารถเขียน diatribe 10 หน้า แต่ถ้าคุณเพียงแค่เขียนแอพพลิเคชั่นทิ้งสำหรับ Company X .. ใครจะแคร์ แต่ถ้าคุณกำลังพัฒนาผลิตภัณฑ์ซอฟต์แวร์ ... คุณจะต้องมีความรู้มากกว่านี้

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

โพสต์นี้ค่อนข้างอ่านยาก (ผนังข้อความ) คุณจะช่วยแก้ไขมันให้เป็นรูปร่างที่ดีขึ้นได้ไหม

— ริ้น

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

— Sinaesthetic

ใช่ฉันเห็นด้วยค่อนข้างฉันหมายถึงรูปแบบที่จัดตั้งขึ้นโดย Martin Fowler และ Carig Lairman ในตอนท้ายของวันฉันไม่สามารถใช้ CTEs, PARTITION BY หรือ CROSS ใช้ได้ ฉันไม่สามารถใช้ IDataReader ซึ่งอนุญาตให้หน่วยความจำเหลือน้อย นอกจากนี้เมื่อฉันรัน SQL Trace และดูสิ่งที่ EF ส่งข้ามสายฉันรู้สึกราวกับว่าฉันอาจ

— พุ่ง

0

ลองใช้งานได้ที่: http://efvote.wufoo.com/forms/ado-net-entity-framework-vote-of-no-confidence/

ประเด็นหลักคือ:

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

โปรดทราบว่าลิงก์ด้านบนกำลังพูดถึง EF1

ลิงค์นี้: http://ormeter.net/แสดงว่า EF นั้นไม่ดีที่สุดเมื่อเทียบกับ ORM อื่น ๆ ในด้านประสิทธิภาพและการสนับสนุน LINQ

— M.Sameer
แหล่งที่มา

โปรดจำไว้ว่าสิ่งนี้ถูกโพสต์เมื่อ EF 1 ยังเพิ่งเปิดตัว (หรืออาจยังอยู่ในช่วงเบต้า) สถานการณ์ดีขึ้นมากในวันนี้เมื่อใช้ EF 4 และปัญหาต่าง ๆ ที่เกิดขึ้นในการโหวตไม่มั่นใจได้รับการแก้ไข

— RationalGeek

จุดสุดท้ายยังคงนับและมีความสำคัญมาก

— M.Sameer

1

รุ่นแรกของ EF คือ 3.5 ไม่มีรุ่นใหญ่สี่รุ่นของ EF ที่เปิดตัว

— Matt Greer

3

@ แมทว่าถูกต้อง แต่เวอร์ชันปัจจุบันเรียกว่า EF 4 เพื่อให้สอดคล้องกับส่วนที่เหลือของการกำหนดเวอร์ชัน. NET 4

— RationalGeek

1

ไม่ว่าจะถูกต้องหรือไม่ไม่ควรส่งผลต่อการสรุปลิงก์ คะแนนจะแสดงว่าถูกต้องหรือไม่ :)

— Adam Lear