เราควรใช้ Entity Framework หรือไม่

31

ขณะนี้เรามีสแต็กต่อไปนี้:

VS 2005
เว็บฟอร์ม
SQL Server 2005
IIS 6

เรากำลังวางแผนที่จะเปลี่ยนเป็น:

VS 2010
MVC และเว็บฟอร์ม
SQL Server 2008
IIS 7

คำถามของฉันคือเมื่อเราย้ายไปที่ MVC ด้วย VS 2010 เราควรใช้ Entity Framework (หรือ ORM อื่น) micro ORM (เช่นMassive ) หรือ SQL ธรรมดาหรือไม่

บทเรียนทั้งหมดที่ฉันได้อ่านเกี่ยวกับ VS 2010 นั้นมุ่งไปที่การใช้ Entity Framework สำหรับการทำธุรกรรมข้อมูล แต่นั่นจะเป็นไปในอนาคตอันใกล้ (5+ ปี) หรือไม่?

หากเป็นเรื่องสำคัญแอปพลิเคชันของลูกค้าของเราสามารถมีผู้ใช้งานตั้งแต่ 10 - 1,000 คน

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

คุณกำลังใช้งาน Linq-to-SQL อยู่หรือเปล่า?

— Morgan Herlocker

เรากำลังใช้พารามิเตอร์ SQL

— guanome

4

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

— NoChance

2

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

— rmac

@rmac มันเป็นฐานข้อมูลใหม่

— guanome

45

ฉันเพิ่งเปลี่ยนจากการใช้แบบสอบถาม SQL ในบรรทัดเป็นการใช้ EF และนี่คือสิ่งที่ฉันพบ:

ข้อดี

เร็วกว่ามากในการสร้าง DAL (ไม่ชอบเขียนแบบสอบถาม SQL!)
บำรุงรักษาง่ายกว่ามาก
ไม่จำเป็นต้องจำที่จะแยกวิเคราะห์อินพุตของฉันอีกต่อไปก่อนสร้างคำสั่ง SQL ในบรรทัดซึ่งหมายถึงโอกาสที่น้อยลงในการโจมตี SQL injection (แน่นอนมันยังคงเป็นไปได้ขึ้นอยู่กับแบบสอบถามของคุณ แต่มีโอกาสน้อยกว่ามาก)

จุดด้อย

ไม่สามารถครอบคลุมหลายฐานข้อมูล ... อย่างน้อยก็ไม่สะดวก
เอนทิตีทั้งหมด (ตารางมุมมอง ฯลฯ ) จำเป็นต้องมีคีย์หลัก
หากคุณต้องการอัปเดตคอลัมน์เดียวในตารางคอลัมน์ที่ต้องการ 100+ รายการ (ไม่ใช่การออกแบบตารางของฉัน) คุณต้องดึงคอลัมน์ทั้งหมด 100 คอลัมน์เพื่อทำการอัปเดต หรือใช้กระบวนงานที่เก็บไว้
ฉันมีปัญหากับค่าเริ่มต้นบางอย่างที่กำหนดไว้บนเซิร์ฟเวอร์ SQL ที่ไม่ได้รับการดึงลงในโมเดลเอนทิตีหลังจากมีการเพิ่มเรคคอร์ดใหม่ โดยทั่วไปจะเป็นค่าที่คำนวณหรือค่าที่เพิ่มใน INSERT Trigger
ในบางครั้งแบบสอบถาม SQL จะเขียนไม่ดีและดำเนินการช้า ถ้าคุณมีคิวรีที่รันช้าให้รันการติดตาม SQL เพื่อดูว่า EF กำลังทำอะไรอยู่ เป็นไปได้ที่คุณจะสามารถทำงานการสืบค้นนั้นอีกครั้งว่าเป็น SP หรือดู สิ่งนี้ไม่ได้เกิดขึ้นบ่อยครั้ง
ฉันมีปัญหาเล็กน้อยกับการพยายามสร้างความสัมพันธ์ระหว่างตารางที่ไม่มี Foreign Key ที่กำหนดไว้ใน SQL Server โดยปกติแล้วเป็นเพราะฉันพยายามสร้าง1:0-1ความสัมพันธ์ที่ EF ต้องการใช้1:0-*

ฉันไม่ใช่ผู้เชี่ยวชาญของ EF ดังนั้นฉันอาจพลาดบางสิ่ง เหล่านี้เป็นเพียงรายการที่ฉันรู้ว่าฉันได้พบในอดีตเมื่อเปลี่ยนจาก inline SQL เป็น Entity Framework ฉันดีใจที่ฉันได้ทำสวิทช์ แต่มีหลายครั้งที่ฉันเกลียด EF จริง ๆ เนื่องจากนิสัยใจคอของมัน

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

7

+1 สำหรับคำตอบโดยละเอียดและเป็นระเบียบ "เอนทิตีทั้งหมด (ตารางมุมมองและอื่น ๆ ) ต้องใช้คีย์หลัก" ดูเหมือนข้อ จำกัด ที่สมเหตุสมผลมากกว่าการต่อต้าน

— NoChance

2

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

— Rachel

1

เพียงลองใช้ EF ในเว็บแอพ N-Tier ที่ไม่ได้เชื่อมต่อ - อัพเดทเอนทิตีในเซสชั่นและความสัมพันธ์ MM, hmmmmm สนุกมาก!

— Vidar

5

เอนทิตี @EmmadKareem ต้องการคีย์หลักที่มีคุณค่าเดียว - การใช้คีย์ผสมเป็นฝันร้ายใน EF นี่เป็นการแย้งมากกว่าการ จำกัด ที่สมเหตุสมผล

— Kirk Broadhurst

1

ฉันจะบอกว่าการรักษาความปลอดภัยเป็นปัญหาอื่น หลายคนคิดว่าการเข้าถึงฐานข้อมูลทั้งหมดควรดำเนินการตามขั้นตอนที่เก็บไว้พร้อมกับบทบาทของฐานข้อมูลที่เกี่ยวข้องกับ procs เพื่อพิจารณาว่าการเข้าสู่ระบบใดที่สามารถดำเนินการกับโปรแกรมที่จัดเก็บไว้ได้ กฎนี้ใช้กับ EF / LINQ ในการสร้างข้อความค้นหา ฉันเคยใช้ EF แต่ได้เจอลูกค้า ( ไอ Microsoft) ที่มีข้อกำหนดด้านความปลอดภัยเหล่านี้

— มิก

12

Entity Framework เป็นเครื่องมือเพิ่มประสิทธิภาพ ถ้าคุณไม่มีเหตุผลที่ดี (เช่นคุณอยู่บน SQL 2000 หรือไม่มีเวลาที่จะเล่นกับเทคโนโลยี) จากนั้นใช้เครื่องมือที่ดีที่สุดในการกำจัดของคุณ

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

Entity Framework ได้รับการสนับสนุนอย่างแข็งขันจาก Microsoft ไม่มีใครมีลูกบอลคริสตัลวิเศษที่จะพูดว่า "การสนับสนุนจะมีอายุ X ปี" ฉันไม่เห็นเหตุผลที่จะเชื่อว่า Entity จะตายในอีก 5 ปีข้างหน้า

— P.Brian.Mackey
แหล่งที่มา

3

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

— ocodo

3

Slomojo อาจเป็นเพราะคุณมีคำจำกัดความที่แตกต่างจากโลกที่เหลือของคำว่า 'Dead' เพราะ LinqToSql ไม่ได้รับการพัฒนาอย่างแข็งขันอีกต่อไป คุณจะยังสามารถใช้งานได้ 10-20 ปีนับจากนี้

— Boris Yankov

4

โซลูชันที่เป็นไปได้อีกอย่างหนึ่งคือการใช้ Entity Framework Library อื่นที่ไม่ใช่ของ VS ที่มาพร้อมกับเว็บ

แนวคิดเฟรมเวิร์กเอนทิตี / เลเยอร์ 3 อยู่ที่นั่นมาระยะหนึ่งแล้วและได้ทำงานกับไลบรารีที่กำหนดเองหลายรายการเช่นเดียวกับนักพัฒนาอื่น ๆ ก่อนที่ Microsoft จะเผยแพร่เฟรมเวิร์ก "ทางการ" ของตัวเอง

ข้อดี

มีประโยชน์ของ Entity (DAL) framework โดยไม่ต้องติดอยู่กับการเปลี่ยนแปลงของ library / framework คงที่ของ Microsoft

การเพิ่มคุณสมบัติให้กับห้องสมุดที่อาจไม่สามารถใช้ได้กับห้องสมุดอย่างเป็นทางการที่มีอยู่เช่นการใช้แบรนด์ dtabase หลายแห่ง

จุดด้อย

ต้องมีการสนับสนุนห้องสมุดหรือเครื่องมือ มันเป็นเรื่องธรรมดามากที่จะมีเครื่องมือสร้างรหัสเอนทิตีเพื่อสร้าง enitites

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

ฉันพบคำตอบนี้สับสนมาก มี Entity Framework เพียงหนึ่งเดียว (ที่มีตัวอักษรพิมพ์ใหญ่) ซึ่งเป็นสิ่งที่ Microsoft สร้างขึ้น คุณหมายถึง "use mapper relational object" หรือไม่ Entity Framework ไม่ใช่คำศัพท์ทั่วไป - เป็นชื่อ ORM ของ Microsoft

— NickG

ควรมี "Microsoft Entity Framework" แนวคิด "Entity Framework" นั้นมีมานานหลายปีแล้ว

— umlcat

3

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

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

— ทอมสไควร์ส
แหล่งที่มา

3

+1 สำหรับการแนะนำไม่ให้เขียนรหัสทำงานอีกครั้ง

— NoChance

2

ในสถานการณ์ของคุณฉันจะใช้ Entity Framework แน่นอนฉันพบว่าทำงานได้ดีกับ MVC
นี่คือเหตุผลและพอยน์เตอร์ที่แท้จริง

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

มีหลายสิ่งที่คุณจะต้องเรียนรู้เกี่ยวกับการใช้ ORM

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

สิ่งที่ต้องพิจารณา

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

ฉันจะขอแนะนำวิธีการรหัสแรกแม้ว่าคุณจะมีฐานข้อมูลที่มีอยู่

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

— แดเนียลน้อย
แหล่งที่มา