คำถามติดแท็ก entity-framework

ORM ที่สร้างขึ้นโดย Microsoft และพร้อมใช้งานเป็นส่วนหนึ่งของ. Net Framework 3.5 และใหม่กว่า

1
เป็นรหัสแรกที่มีการโยกย้ายหรือเครื่องมือข้อมูลเซิร์ฟเวอร์ SQL เหมาะสมกว่าหรือไม่
ฉันได้รับสเป็คเพื่อสร้างเว็บไซต์ MVC4 ใหม่มันจะไม่ใหญ่เกินไปในตอนแรก แต่ฉันคิดว่ามันจะเติบโตขึ้นเมื่อธุรกิจได้รับแนวคิดใหม่ ๆ การใช้. NET 4.5 ASP.NET MVC4 และ EF ฉันต้องเลือกระหว่างโค้ดก่อนด้วยการโยกย้ายหรือ Sql Server Data Tools (SSDT) ​​สำหรับการจัดการฐานข้อมูลของฉัน ด้วย SSDT ฉันสามารถควบคุมฐานข้อมูลของฉันในโครงการซึ่งเป็นส่วนหนึ่งของโซลูชันของฉันและจัดการการเปลี่ยนแปลงทุกอย่างตั้งแต่การพัฒนาไปจนถึงการผลิตและอื่น ๆ โดยใช้ไฟล์ dacpac ประสบการณ์ของฉันเกี่ยวกับโค้ดแรกจาก MVC3 ไม่ได้ใช้เกินกว่าการพัฒนาเนื่องจากตัวเลือกฐานข้อมูลที่ จำกัด มันจะจบลงด้วยการวาง Db ลงบนการเปลี่ยนแปลงรูปแบบหรือจัดการกับการเปลี่ยนแปลง Db ด้วยตนเอง อย่างไรก็ตามฉันถูกชักจูงให้เชื่อกับการโยกย้าย MVC4 ซึ่งไม่เป็นเช่นนั้นอีกต่อไปและตอนนี้ฉันสามารถผลักดันการอัปเดตไปยัง Db ได้แล้ว ดังนั้นคำถามของฉันคือแบบใดที่มีประสิทธิภาพมากที่สุดในการใช้โดยอิงจากการประหยัดเวลา / ความพยายามในการพัฒนา แต่ยังสามารถปรับขนาดได้และสามารถจัดการกับการเปลี่ยนแปลงการผลิตได้ ฉันชอบโค้ดก่อนและความสามารถในการสร้างฐานข้อมูลของฉันจากแบบจำลองตอนนี้การแนะนำการย้ายข้อมูลทำให้สามารถใช้งานได้จริงหรือไม่?

3
Entity Framework Entity - ข้อมูลบางอย่างจากบริการบนเว็บ - สถาปัตยกรรมที่ดีที่สุด?
ขณะนี้เรากำลังใช้ Entity Framework เป็น ORM ในเว็บแอปพลิเคชั่นไม่กี่แห่งและจนถึงตอนนี้มันเหมาะกับเราและข้อมูลทั้งหมดของเราจะถูกเก็บไว้ในฐานข้อมูลเดียว เราใช้รูปแบบพื้นที่เก็บข้อมูลและมีบริการ (โดเมนเลเยอร์) ซึ่งใช้สิ่งเหล่านี้และส่งคืนเอนทิตี EF โดยตรงไปยังตัวควบคุม ASP.NET MVC อย่างไรก็ตามข้อกำหนดได้เกิดขึ้นเพื่อใช้ API ของบุคคลที่สาม (ผ่านบริการบนเว็บ) ซึ่งจะให้ข้อมูลเพิ่มเติมที่เกี่ยวข้องกับผู้ใช้ในฐานข้อมูลของเรา ในฐานข้อมูลผู้ใช้ในพื้นที่ของเราเราจะจัดเก็บ ID ภายนอกซึ่งเราสามารถมอบให้กับ API เพื่อรับข้อมูลเพิ่มเติม มีข้อมูลค่อนข้างน้อย แต่เพื่อความเรียบง่ายหนึ่งในนั้นเกี่ยวข้องกับ บริษัท ของผู้ใช้ (ชื่อผู้จัดการห้องชื่อตำแหน่งงาน ฯลฯ ) ข้อมูลนี้จะถูกใช้ในสถานที่ต่าง ๆ ทั่วทั้งเว็บแอปของเราซึ่งต่างจากการใช้งานในที่เดียว ดังนั้นคำถามของฉันคือที่ที่ดีที่สุดในการเติมและเข้าถึงข้อมูลนี้ที่ไหน เนื่องจากมีการใช้งานในสถานที่ต่าง ๆ จึงไม่เหมาะสมที่จะดึงข้อมูลมาใช้เป็นหลักในทุกที่ที่เราใช้ในเว็บแอปพลิเคชัน - ดังนั้นจึงเหมาะสมที่จะส่งคืนข้อมูลเพิ่มเติมนี้จากเลเยอร์โดเมน ความคิดเริ่มต้นของฉันคือการสร้างคลาสโมเดล wrapper ซึ่งจะมีเอนทิตี EF (EFUser) และคลาส 'ApiUser' ใหม่ที่มีข้อมูลใหม่ - และเมื่อเราได้รับผู้ใช้เราจะได้ EFUser …

3
DDD กับ ORM ตรรกะทางธุรกิจควรไปที่ใด
ฉันเคยใช้เครื่องมือ MDA (สถาปัตยกรรมที่ขับเคลื่อนด้วยโมเดล) ในอดีตที่เราทำโมเดลผ่าน UML และสิ่งนี้ได้สร้างเอนทิตีธุรกิจ (โมเดลโดเมนของเรา) และ ORM (การทำแผนที่ ฯลฯ ) ท่ามกลางสิ่งอื่น ๆ รหัสธุรกิจและบริการจำนวนมากที่ทำงานบนโดเมนนั้นเป็นส่วนหนึ่งของแบบจำลองและที่เก็บของเราส่งคืนเอนทิตีธุรกิจ (ดังนั้นจึงเป็นไปไม่ได้ที่จะเปลี่ยนไปใช้ ORM อื่น (ไม่ใช่ที่เราต้องการ)) อย่างไรก็ตามตอนนี้ฉันกำลังเริ่มโครงการและฉันต้องการคิดในแง่ของ DDD จนถึงตอนนี้ฉันรู้สึกราวกับว่าฉันวางตรรกะทางธุรกิจของฉันในรูปแบบโดเมนของฉันและผ่านที่เก็บฉันจะทำงานร่วมกับ ORM (ซึ่งฉันเคยเลือก) อย่างไรก็ตามถ้าฉันต้องการใช้เครื่องมือ MDA สำหรับส่วน ORM ของแอปพลิเคชันต่อไปโมเดลที่สร้างขึ้นที่นี่จะเป็นโลหิตจางมาก (เช่นไม่มีตรรกะทางธุรกิจ) ในทำนองเดียวกันถ้าฉันใช้ Entity framework (.net) หรือ NHibernate สำหรับ ORM ของฉันมันก็จะเป็นแบบจำลองโลหิตจางด้วย? ฉันไม่แน่ใจว่าคุณจะใช้ตรรกะทางธุรกิจที่ใดถ้าฉันใช้ NHibernate ฉันถูกต้องในการคิดแบบนี้ในคำอื่น ๆ ที่มี DDD ตรรกะทางธุรกิจทั้งหมดในโดเมนและเพียงแค่ใช้ ORM สำหรับการคงอยู่ผ่านทางที่เก็บ?

4
LINQ กับ Data Access Layer
ฉันสอนตัวเองอยู่เสมอเพื่อจัดการรหัสการเข้าถึงข้อมูลใน 'เลเยอร์' แยกจากกันอย่างสมบูรณ์เพื่อตรรกะทางธุรกิจและรหัส UI ของฉัน นี้ได้เสมอสถาปัตยกรรมที่ดีมากสำหรับผมและใด ๆ 'กฎ' หรือการปฏิบัติที่ดีที่สุดที่ฉันเห็นยังคงจัดการเพื่อให้พอดีกับรูปแบบของการเข้ารหัสนี้โดยเฉพาะอย่างยิ่งSingle รับผิดชอบหลักการ สำหรับโครงการบ้านส่วนใหญ่ของฉันฉันจะใช้ ORM ของฉันเองที่ฉันสร้างขึ้นซึ่งฉันตั้งใจจะทำโอเพ่นซอร์สเสมอ อย่างไรก็ตามตั้งแต่นั้นมา LINQ ก็พร้อมใช้งานซึ่งคล้ายกับวิธีการออมของฉัน (แต่ .. ดีกว่า) ก่อนหน้านี้ฉันไม่สามารถทำอะไรกับ ORM ของฉันที่ฉันไม่สามารถทำได้กับ LINQ (ยกเว้นบิตของการรวม REST) ดังนั้นคำถามของฉันคือ LINQ เป็น Data Access Layer ใหม่ของฉันหรือไม่ ฉันต้องการเลเยอร์นี้อีกเลยหรือไม่ BLL ของฉันควรคุยกับ LINQ โดยตรงหรือไม่ หรือการปฏิบัติที่ไม่ดีนี้ยังคง? แก้ไข: คำถามเดิมหมายถึง LINQ to Entities แต่มีคำตอบที่น่าสนใจมากมายเกี่ยวกับ LINQ กับ SQL ประชาชนคิดอะไรกับทั้งคู่? ฉันรวบรวมกว่า LINQ …

7
Entity Framework พร้อมสำหรับการผลิตหรือไม่ [ปิด]
ปิด คำถามนี้เป็นคำถามความคิดเห็นตาม ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้สามารถตอบข้อเท็จจริงและการอ้างอิงได้โดยแก้ไขโพสต์นี้ ปิดให้บริการใน5 ปีที่ผ่านมา ฉันกำลังมองหา Entity Framework สำหรับโครงการใหม่ที่ฉันจะเข้าร่วมและเป็นส่วนหนึ่งของงานวิจัยของฉันฉันขอให้ผู้เชี่ยวชาญในอุตสาหกรรมว่ามีความมั่นคงและพร้อมสำหรับการใช้งาน 'โลกแห่งความจริง' ในการทำงานคือ: EF NHibernate DevExpress XPO ฉันมีประสบการณ์อย่างมากกับ XPO แล้ว แต่ฉันก็ไม่พอใจกับมันเป็นพิเศษ

2
ฉันสามารถอัปเดตวัตถุที่แนบโดยใช้วัตถุที่แยกออกมา แต่เท่ากันได้หรือไม่
ฉันดึงข้อมูลภาพยนตร์จาก API ภายนอก ในระยะแรกฉันจะขูดภาพยนตร์แต่ละเรื่องแล้วใส่ลงในฐานข้อมูลของฉันเอง ในระยะที่สองฉันจะอัปเดตฐานข้อมูลเป็นระยะโดยใช้ API "การเปลี่ยนแปลง" ของ API ซึ่งฉันสามารถสืบค้นเพื่อดูว่าภาพยนตร์เรื่องใดที่ข้อมูลของพวกเขาเปลี่ยนไป เลเยอร์ ORM ของฉันคือ Entity-Framework คลาสภาพยนตร์มีลักษณะดังนี้: class Movie { public virtual ICollection<Language> SpokenLanguages { get; set; } public virtual ICollection<Genre> Genres { get; set; } public virtual ICollection<Keyword> Keywords { get; set; } } ปัญหาเกิดขึ้นเมื่อผมมีหนังที่ต้องมีการปรับปรุงฐานข้อมูลของฉันจะคิดว่าของวัตถุที่มีการติดตามและคนใหม่ที่ฉันได้รับจากสายการปรับปรุง API .Equals()เป็นวัตถุที่แตกต่างกันโดยไม่คำนึงถึง สิ่งนี้ทำให้เกิดปัญหาเพราะเมื่อฉันพยายามอัปเดตฐานข้อมูลด้วยภาพยนตร์ที่อัปเดตแล้วมันจะแทรกแทนการอัปเดตภาพยนตร์ที่มีอยู่ ฉันมีปัญหานี้มาก่อนด้วยภาษาและวิธีการแก้ปัญหาของฉันคือการค้นหาวัตถุภาษาที่แนบมาแยกพวกเขาออกจากบริบทย้าย PK ของพวกเขาไปยังวัตถุที่อัปเดตและแนบไปกับบริบท …

1
ORM POCOs แทนที่โดเมนหรือไม่
นี่ค่อนข้างคล้ายกับคำถามนี้แต่กว้างขึ้น โดยทั่วไปแล้วด้วย ORMs เช่น EF 4.1 ที่รองรับ POCO ตอนนี้มันสมเหตุสมผลหรือไม่ที่จะให้หน่วยงานโดเมนของคุณเป็นวัตถุที่ยังคงอยู่ในฐานข้อมูลของคุณ ด้วย ORM ที่เก่ากว่าเช่น EF 4 หรือ Linq-to-SQL วัตถุ "ฐานข้อมูล" ของคุณจะถูกสร้างขึ้นโดยอัตโนมัติและเชื่อมต่อกับฐานข้อมูลของคุณอย่างแน่นหนาและดังนั้นสำหรับแอปพลิเคชันที่ไม่น่าสนใจ นำไปทำงาน เป็นความคิดที่มี ORM ที่ใหม่กว่าเพียงแค่สร้างเอนทิตีโดเมนที่มีประสิทธิภาพแล้วมี data-layer ที่ให้การแม็พระหว่างเอนทิตีโดเมนดังกล่าวกับ DBMS ของคุณหรือไม่ ในการเขียนที่ฉันรู้สึกว่านี่เป็นเป้าหมายเสมอแต่ไม่สามารถทำได้อย่างง่ายดายด้วยเครื่องมือที่มีอยู่อย่างน้อยไม่ใช่ในโลก NET

3
พื้นที่เก็บข้อมูลจำเป็นต้องใช้อีกต่อไปใน ASP.net 5 และ EF7 หรือไม่
ฉันโพสต์คำถามเกี่ยวกับ GitHub ให้กับทีม EF ฉันได้รับคำตอบว่าจะเป็นการดีกว่าถ้าถามคำถามนี้ที่นี่ดังนั้นฉันจะคัดลอกและวางไว้ที่นี่เนื่องจากเราเป็นลิงก์เพื่อให้คนอื่นเห็นการตอบกลับใน GitHub ไม่กี่ครั้ง คำถาม: ฉันกำลังทำการวิจัยและมีคนชี้ให้เห็นว่า Line 24 ของ DBContext Class กล่าว DbContext เป็นการรวมกันของรูปแบบของหน่วยงานและที่เก็บข้อมูล นี่หมายความว่าเราไม่จำเป็นต้องแยก EF ออกจากพื้นที่เก็บข้อมูลแล้วใช้และส่วนต่อประสานเพื่อแทรกเข้าไปในคอนโทรลเลอร์ โพสต์ต้นฉบับบน Github: https://github.com/aspnet/EntityFramework/issues/4899 เหตุผลที่ฉันถามนี่คือฉันดูเหมือนจะเข้าไปในจุดที่ฉันเพิ่มวิธีการมากมายในพื้นที่เก็บข้อมูลเช่น GetById, GetByName, GetWithIncludesABC, GetWithIncludes123 ฯลฯ และดูเหมือนจะทำให้ repo สกปรกในใจ

3
วิธีที่ดีที่สุดในการเชื่อมโยงบริบทฐานข้อมูล Entity Framework (รุ่น) กับ ViewModel ใน MVVM WPF คืออะไร
ดังในคำถามข้างต้น: อะไรคือวิธีที่ดีที่สุดในการเชื่อมโยงโมเดลฐานข้อมูล Entity Framework (บริบท) กับ viewModel ใน MVVM (WPF) ฉันกำลังเรียนรู้รูปแบบ MVVM ใน WPF ตัวอย่างจำนวนมากแสดงวิธีการนำโมเดลไปใช้กับ viewModel แต่โมเดลในตัวอย่างนั้นเป็นคลาสที่เรียบง่ายฉันต้องการใช้ MVVM พร้อมกับโมเดลเฟรมเวิร์กเอนทิตี (base first approach) Whats วิธีที่ดีที่สุดในการวางสายเพื่อดู model ขอบคุณสำหรับคำตอบ //ctor of ViewModel public ViewModel() { db = new PackageShipmentDBEntities(); // Entity Framework generated class ListaZBazy = new ObservableCollection<Pack>(db.Packs.Where(w => w.IsSent == false)); } …
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.