Entity Framework 4 เทียบกับ NHibernate [ปิด]

มีการพูดคุยกันมากมายเกี่ยวกับ Entity Framework เวอร์ชันแรกบนเว็บ (เช่นใน stackoverflow) และเป็นที่ชัดเจนว่ามันไม่ใช่ทางเลือกที่ดีเมื่อเรามีทางเลือกที่ดีกว่าเช่น NHibernate อยู่แล้ว แต่ฉันไม่พบการเปรียบเทียบที่ดีของ Entity Framework 4 และ NHibernate เราสามารถพูดได้ว่าวันนี้ NHibernate เป็นผู้นำในบรรดา. NET ORMs แต่เราสามารถคาดหวังให้ Entity Framework 4 แทนที่ NHibernate จากตำแหน่งนี้ได้หรือไม่ ฉันคิดว่าถ้า Microsoft ได้เพิ่มคุณสมบัติที่ดีมากใน EF4 มันสามารถทำให้เกิดการแข่งขันที่ดีกับ NHibernate เนื่องจากมีการรวม Visual Studio ใช้งานได้ง่ายขึ้นและความพึงพอใจจะมอบให้กับผลิตภัณฑ์ MS ในร้านค้าส่วนใหญ่

EF4 มีคำตอบสำเร็จรูปเกี่ยวกับการพัฒนา n-tier ใน "เอนทิตีการติดตามตนเอง" ไม่มีใครเผยแพร่รหัสเทียบเคียงสำหรับ NHib

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

อัปเดต:ฉันไม่ได้ใช้ Entity Framework ตั้งแต่เวอร์ชัน 4.0 ดังนั้นคำตอบของฉันจึงอาจล้าสมัย ฉันยังคงใช้ NH หรือ ADO .NET บริสุทธิ์ในโครงการของฉัน และฉันไม่อยากดูว่ามีอะไรใหม่ใน EF ตั้งแต่ 4.0 เพราะ NH ทำงานได้อย่างสมบูรณ์แบบ

จริงๆแล้วมันค่อนข้างง่ายที่จะเปรียบเทียบเมื่อคุณใช้ทั้งสองอย่าง มีข้อ จำกัด ร้ายแรงบางประการกับ EF4 ฉันสามารถตั้งชื่อบางอย่างที่ฉันพบด้วยตนเอง:

ปัญหา EF4:

• การโหลดและสร้างผลลัพธ์อย่างกระตือรือร้น: ระบบโหลด EF4 กระตือรือร้น (รวม ("เส้นทาง")) สร้าง SQL ที่ไม่เหมาะสมด้วยการวนลูป JOIN ซึ่งจะทำให้เวลาดำเนินการหลายพันครั้ง (ไม่ใช่ตามตัวอักษร) ช้าลงสำหรับความสัมพันธ์แบบกลุ่มต่อกลุ่มจากนั้นจึงเขียน SQL ด้วยมือ (มัน ใช้ไม่ได้อย่างมีประสิทธิภาพ)
• Materializer ไม่สามารถกำหนดเอนทิตีที่เกี่ยวข้องได้ : หากคุณคิดว่าสามารถเอาชนะปัญหาก่อนหน้านี้ได้โดยการให้แบบสอบถาม SQL ของคุณเองคุณคิดผิด EF4 ไม่สามารถกำหนดเอนทิตีที่เกี่ยวข้อง (แมป) จากการสืบค้น JOIN SQL ได้มันสามารถโหลดข้อมูลจากตารางเดียวเท่านั้น (ดังนั้นหากคุณมี Order.Product สินค้า SELECT * FROM order LEFT JOIN จะเริ่มต้นเฉพาะวัตถุ Order เท่านั้น Product จะยังคงเป็นโมฆะ คิดว่ามีการดึงข้อมูลที่จำเป็นทั้งหมดในแบบสอบถามเพื่อเริ่มต้น) สิ่งนี้สามารถเอาชนะได้โดยใช้ส่วนเสริมชุมชน EFExtensions แต่โค้ดที่คุณจะต้องเขียนมันน่าเกลียดมาก (ฉันลองแล้ว)

• เอนทิตีการติดตามตนเอง: หลายคนบอกว่าเอนทิตีการติดตามตนเองนั้นยอดเยี่ยมสำหรับการพัฒนาระดับ N รวมถึงคำตอบยอดนิยมในชุดข้อความนี้ คิดว่าฉันยังไม่ได้ลองพวกเขาฉันบอกได้เลยว่ามันไม่ใช่ทุกอินพุตสามารถปลอมแปลงได้คุณไม่สามารถใช้การเปลี่ยนแปลงที่ผู้ใช้ส่งให้คุณและนำไปใช้กับฐานข้อมูลทำไมไม่ให้ข้อมูลโดยตรงกับผู้ใช้ เข้าถึงฐานแล้ว? วิธีใดก็ตามที่คุณจะต้องโหลดข้อมูลผู้ใช้กำลังจะเปลี่ยนจาก DB ตรวจสอบว่ามีอยู่ | ไม่มีอยู่ทำการตรวจสอบสิทธิ์ ฯลฯ เป็นต้นคุณไม่สามารถไว้วางใจผู้ใช้ในสถานะของเอนทิตีที่เขากำลังส่งไปยังเซิร์ฟเวอร์ได้อยู่ดี ต้องโหลดเอนทิตีนี้จาก DB และพิจารณาว่าเป็นสถานะและสิ่งอื่น ๆ ดังนั้นข้อมูลนี้จึงไร้ประโยชน์เช่นเดียวกับเอนทิตีการติดตามตนเองเว้นแต่คุณจะทำระบบ n-tier ส่วนตัวที่เชื่อถือได้สำหรับการใช้งานภายในซึ่งในกรณีนี้คุณอาจให้ข้อมูลธรรมดา การเข้าถึงฐานข้อมูล

• การบันทึกเหตุการณ์การรวมตรรกะทางธุรกิจ: EF4 เป็นเหมือนกล่องดำมันทำอะไรบางอย่างและคุณไม่รู้ว่ามันทำอะไร มีเพียงเหตุการณ์เดียวเท่านั้น OnSavingChanges ที่คุณสามารถใส่ตรรกะทางธุรกิจบางอย่างที่คุณต้องเรียกใช้ก่อนที่จะมีบางสิ่งเกิดขึ้นกับ DB และหากคุณต้องการใช้การเปลี่ยนแปลงบางอย่างกับวัตถุทางธุรกิจก่อนที่จะเกิดอะไรขึ้นคุณจะต้องขุดใน ObjectStateManager และสิ่งนี้น่าเกลียดจริงๆ รหัสสามารถกลายเป็นขนาดใหญ่ ตัวอย่างเช่นหากคุณใช้รูปแบบพื้นที่เก็บข้อมูลและสิ่งที่ต้องแจ้งเกี่ยวกับการเปลี่ยนแปลงที่เกิดขึ้นกับ DB ในรูปแบบอ็อบเจ็กต์ที่สะอาดคุณจะมีปัญหาในการทำเช่นนี้กับ EF

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

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

แล้ว NHibernate ล่ะ? มันแตกต่างกันอย่างสิ้นเชิงเหมือนกับการเปรียบเทียบ PHP กับ C #, EF4 ก็เหมือนกับในยุคหินเหมือนกับว่า EF มีอายุ 10 ปีหลังจากนั้น NHibernate กำลังอยู่ในระหว่างการพัฒนาและในความเป็นจริง Hibernate เริ่มต้นในปี 2544 หากคุณมีเวลาว่าง หากต้องการเรียนรู้และเปิด Nhibernate ให้ทำ

นี่คือสิ่งที่ NHibernate และ Entity Framework มีไว้สำหรับผู้ชมสองกลุ่มในความคิดของฉัน NHibernate จะเป็นทางเลือกของฉันในการสร้างระบบที่มีการแมปสูตรและข้อ จำกัด ที่ซับซ้อน (โดยทั่วไปคืออะไรก็ตามขององค์กร) หากฉันต้องการเริ่มต้นใช้งานได้ง่ายด้วยการเข้าถึงข้อมูลอย่างง่ายฉันจะใช้ Entity Framework หรือ LINQ-to-SQL NHibernate ไม่มีประสบการณ์ "ลากแล้ววาง" ที่ชัดเจนเหมือน EF ทั้งสองมีจุดแข็งและข้อเสีย การเปรียบเทียบแอปเปิ้ลกับแอปเปิ้ลอย่างตรงไปตรงมาทำให้คุณไม่มีที่ไหนเลย

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

แก้ไข 13/8/2555:

Entity Framework เป็นแบบโอเพนซอร์สและตอนนี้รวมอยู่ใน Mono ตั้งแต่ 2.11.3 คำตอบนี้ล้าสมัยและไม่ควรพึ่งพา

http://weblogs.asp.net/scottgu/archive/2012/07/19/entity-framework-and-open-source.aspx

สิ่งนี้ของฉันคือ EF4.0 มาไกลตั้งแต่ 1.0 และกำลังตามหา Nhibernate ในการทำงาน แต่มันยังไม่หมดแค่นั้น

อย่างไรก็ตามไมโครซอฟท์ทำนอกกรอบและทำ 100% ในสิ่งที่ 95% ของแอปพลิเคชันต้องทำ อย่างไรก็ตาม NHibernate ได้ทำสิ่งเดียวกันนี้มาหลายปีแล้ว มาเวอร์ชัน 5.0 หรือ 6.0 อาจตามทันหรือเหนือกว่า NHibernate

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

NHibernate เป็นผลิตภัณฑ์ที่เติบโตเต็มที่โดยใช้เวลาไม่กี่ปีกับ EF และมักจะทำทุกอย่างที่คุณอยากทำและบางอย่าง เป็น ORM ที่ดีที่สุดมาระยะหนึ่งแล้วและผู้คนจำนวนมากใช้มัน

ฉันคิดว่าความจริงที่ว่า EF 4 จะมีความสามารถในการใช้ POCO และการโหลดแบบขี้เกียจรอการตัดบัญชีจะเป็นเรื่องใหญ่มาก แน่นอนฉันเห็นว่ามันดึงดูดด้วยการเปิดตัวใหม่

มีแนวโน้มที่ชัดเจนของความนิยม EF ที่เพิ่มขึ้นมากกว่า NHibernate โปรดดูภาพ

2 เซ็นต์ของฉัน: เราใช้ ef บนไคลเอนต์เดสก์ท็อปของเราสำหรับ cahing ฯลฯ - ไม่มีการโหลดสูง NHib บนฝั่งเซิร์ฟเวอร์ - ใช้เซสชัน Stateless การสร้างรหัสไฮโลและแบทช์ ค่อนข้างรวดเร็วในการแทรกข้อความ 3k + ใน db ต่อวินาที นอกจากนี้ยังมีความยืดหยุ่นสูงและรองรับ dbs จำนวนมากซึ่งเป็นสิ่งสำคัญสำหรับผลิตภัณฑ์ของเรา

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

วัตถุโหลดและจัดเก็บผ่าน SP มาตรฐาน วิธีนี้ช่วยให้สามารถใช้การเข้าสู่ระบบ sql สองรายการ หนึ่งสำหรับการเข้าถึงคลาสผ่าน SPs (สิทธิ์ดำเนินการเท่านั้น) และอีกอันสำหรับโมดูล linq ลอจิคัลที่อนุญาตให้เข้าถึงตารางโดยตรง

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

ATM มุมมองของฉันเกี่ยวกับ EF คือ: "มันถูกสร้างขึ้นสำหรับระบบบิตเล็ก ๆ ที่ค่อนข้างเล็กจริงๆโดยมีตารางไม่เกิน 3 ตารางที่มีความสัมพันธ์น้อยกว่า 1 (0 ดีกว่า)"

แล้วทำไมฉันถึงคิดแบบนั้น? 1. ลองอัปเดตกราฟที่ไม่ได้เชื่อมต่อและดูแบบจำลองของคุณ

1. ลองสร้าง TPH ด้วยต้นไม้ที่สืบทอดมาอย่างลึกซึ้งแล้วคุณจะพบว่าคุณถูกไล่ไปที่ลำดับชั้นเดียวไม่เช่นนั้นระบบจะพัง

2. พยายามทำแบบสอบถามที่ยุ่งยากมากขึ้นและดูทั้งระบบกินสแต็กออกไป: D ... ล้นเกิดขึ้นบ่อยมาก

3. ประเภทข้อมูล XML ของแผนที่ขึ้นอยู่กับส่วนขยายหรือคุณสมบัติ NotMapped ที่ "เกลียด" ที่สุด ... และที่แย่กว่านั้นคือ

4. ลองผสมการสืบค้น SQL ลงใน Linq เพื่อการสืบค้นขั้นสุดท้ายเพิ่มเติมแล้วคุณจะทำลายกำแพงฮ่า ๆ

5. และสิ่งสุดท้ายและสำคัญที่สุด EF ไม่รองรับสูตรคุณสมบัติ ('ทรัพยากรที่ยอดเยี่ยมที่ NH มีสำหรับฐานข้อมูลเดิม') และไม่รองรับการแมปประเภทที่ซับซ้อนสำหรับตารางเดียวกันและตารางที่เกี่ยวข้อง

นั่นคือ 10cc ของฉัน