CodeFirst มีไว้สำหรับการใช้งานขนาดใหญ่หรือไม่?

ฉันได้อ่านข้อมูลเกี่ยวกับ Entity Framework โดยเฉพาะ EF 4.1 และตามลิงก์นี้ ( http://weblogs.asp.net/scottgu/archive/2010/07/16/code-first-development-with-entity-) framework-4.aspx ) และเป็นแนวทางสำหรับ Code First

ฉันคิดว่ามันเรียบร้อย แต่ฉันสงสัยว่า Code First ควรจะเป็นเพียงวิธีแก้ปัญหาสำหรับการพัฒนาอย่างรวดเร็วซึ่งคุณสามารถกระโดดได้อย่างถูกต้องโดยไม่ต้องวางแผนอะไรมาก

ฉันอาจจะมีผู้ว่าที่นั่น แต่เมื่อฉันอ่านโพสต์เหล่านั้นจาก Hanselman และ Gutherie จากนั้นอ่านหนังสือของJulia Lermanใน Entity Framework ฉันมีช่วงเวลายากมากที่ใช้รหัสก่อน ในการสร้างแอปพลิเคชั่นเป็นเวลาหลายปีของฉันฉันได้ลงเส้นทางมากมายทั้งที่ถูกบังคับโดยกระบวนการและโดยทางเลือกและพบว่าฉันประสบความสำเร็จมากขึ้นเมื่อดูมุมมองข้อมูลเป็นศูนย์กลางเมื่อสร้างแอปพลิเคชัน

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

แอปพลิเคชันขนาดเล็กอาจมีข้อยกเว้น แต่ฉันจะใช้วิธีการที่เป็นศูนย์กลางข้อมูลของฉันต่อไป

ฉันไม่เห็นว่าทำไม CodeFirst จึงไม่สามารถใช้ในโครงการขนาดใหญ่ขององค์กรได้ ฉันจะบอกว่าฉันใช้ EF CodeFirst ในหลายโครงการหนึ่งที่ฐานข้อมูลถูกสร้างขึ้นโดยรุ่น EF CodeFirst ของฉันและที่สองที่ EF CodeFirst ถูกแมปกับฐานข้อมูลที่มีอยู่

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

ตัวอย่างเช่นในหนึ่งในโครงการของฉันเลเยอร์ธุรกิจเรียกฐานข้อมูลโดยตรงผ่าน linq ฉันใช้ Linq เพื่อแยกเลเยอร์ฐานข้อมูลออกและใช้ CodeFirst เพื่อแมป POCO ของฉันลงในสคีมาฐานข้อมูล ในกรณีนี้ CodeFirst ทำให้การรักษาความแตกต่างระหว่างการประชุม DB (ชื่อความสัมพันธ์และชื่อตาราง) และชื่อคลาส C # ของฉันง่ายขึ้นมากและฉันสามารถทำการเปลี่ยนแปลงฐานข้อมูลได้โดยไม่ต้องกระทบกับการทำงานของชั้นธุรกิจของฉันกับฐานข้อมูล

อย่างไรก็ตามในโครงการอื่นฉันมีการเข้าถึงฐานข้อมูลที่เป็นนามธรรมในรูปแบบพื้นที่เก็บข้อมูลที่ไม่ทั่วไปและวิธีการที่เก็บ * ของฉันมีหน้าที่รับผิดชอบในการเรียกใช้แบบสอบถามบนฐานข้อมูล แต่เพียงผู้เดียวและส่งคืนวัตถุจริง (ไม่ใช่IQueryable<T>s) ในอินสแตนซ์นี้วิธีการเก็บข้อมูลจะแปลงเอนทิตี DB เป็นเอนทิตี POCO และในกรณีนี้ CodeFirst ไม่ได้ให้ประโยชน์กับคุณมากเท่าที่ CodeFirst POCOs มีอายุสั้นและถูกแปลงเป็นคลาสเลเยอร์ธุรกิจ C # อย่างรวดเร็ว

ท้ายที่สุดมันขึ้นอยู่กับการจัดโครงสร้างของทีมและความสะดวกสบายของทีม (หรือผู้อาวุโส) กับวิศวกรที่ไม่ใช่ DBA ที่ปรับเปลี่ยนสกีมาฐานข้อมูลและการเปลี่ยนแปลงสคีมามีผลต่อโครงสร้างโค้ดของคุณมากน้อยเพียงใด ด้วย CodeFirst แมปกับฐานข้อมูลที่มีอยู่มันเป็นเรื่องธรรมดาสำหรับฉันที่จะแมปคุณสมบัติกับชื่อคอลัมน์ใหม่โดยไม่ต้องเปลี่ยนชื่อทั่วโลกของชื่อคุณสมบัตินั้นซึ่งเป็นปัจจัยโดยเฉพาะอย่างยิ่งเมื่อคุณพูดถึงชื่อที่เหมาะสมกว่า สำหรับฟิลด์ฐานข้อมูลแทนคุณสมบัติ C # นอกจากนี้ยังเป็นเรื่องเล็กน้อยสำหรับฉันที่จะเพิ่มการสนับสนุนโค้ดสำหรับเขตข้อมูลฐานข้อมูลใหม่โดยไม่ต้องปรับเปลี่ยนเอนทิตี C # ของฉันอย่างสมบูรณ์ (หนึ่งในเหตุผลที่ฉันทิ้ง Linq-to-sql ไปยัง EF CodeFirst จากฐานข้อมูลที่มีอยู่)

รหัสแรกไม่เหมาะสำหรับการใช้งานขนาดใหญ่ การพลิกผันการพัฒนาแอพขนาดใหญ่นั้นใหญ่มาก

โดยทั่วไปวงจรชีวิตของแอปธุรกิจของคุณเป็นเช่น

1. รุ่น 1 อยู่ในการผลิต
2. รุ่น 2 อยู่ในรุ่นเบต้า
3. เวอร์ชัน 3 กำลังอยู่ในระหว่างการพัฒนา
4. เวอร์ชัน 4 กำลังอยู่ในการวางแผน

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

ในที่สุด Code First ใช้ ObjectContext ของ Entity Model, EF รุ่นเก่าที่สร้าง EDMX และการใช้ ObjectContext กับ EntityObject นั้นเพียงพอสำหรับทุกอย่างจริงๆ คุณสามารถปรับแต่งเทมเพลตข้อความเพื่อสร้างรหัสได้อย่างง่ายดาย วิธีการตรวจหาการเปลี่ยนแปลงช้าลงเมื่อใช้งาน ObjectContext แต่แทนที่จะสร้างพร็อกซีทีม EF สามารถปรับปรุงการตรวจจับการเปลี่ยนแปลงได้อย่างง่ายดายแทนการสร้างรหัสใหม่ก่อน

การโยกย้ายอัตโนมัติ

การย้ายถิ่นโดยอัตโนมัติฟังดูดีในทางทฤษฎี แต่เป็นไปไม่ได้ในทางปฏิบัติเมื่อคุณใช้งานจริง มันเป็นการดีสำหรับการทำต้นแบบการพัฒนาการสาธิตอย่างรวดเร็ว

การโยกย้ายรหัสครั้งแรกนั้นไม่เหมาะสมในระบบดังกล่าว เวอร์ชัน 1 และเวอร์ชัน 2 มักจะพูดคุยกับฐานข้อมูลเดียวกัน เวอร์ชัน 3 และเวอร์ชัน 4 มักจัดเตรียมและมีฐานข้อมูลที่แตกต่างกัน

ฐานข้อมูลก่อน

ฐานข้อมูลแรกเป็นวิธีการปฏิบัติมันเป็นเรื่องง่ายที่จะเปรียบเทียบและเห็นภาพและบำรุงรักษาสคริปต์ SQL DBA สามารถทำงานได้อย่างง่ายดาย

เทมเพลตข้อความ

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

สำหรับฉันการคลิกขวาที่ไฟล์. tt และคลิก "เรียกใช้เครื่องมือกำหนดเอง" เป็นขั้นตอนที่เร็วที่สุดและง่ายที่สุดจากนั้นจึงเขียนคลาสการกำหนดค่าและการสร้างแบบจำลอง

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

ฟังดูเหมือนว่า "Code First" มีไว้สำหรับใช้กับ EF ที่มี "agile" มากกว่า (ไม่พิณมากเกินไปในเทอมนั้นฉันไม่จำเป็นต้องหมายถึงระเบียบวิธี) และแอพกรีนฟิลด์ที่คุณไม่มี ตัวแบบข้อมูลที่มีอยู่หรือข้อมูลที่มีอยู่; ประเภทของแอพที่คุณสามารถใช้ Django หรือกรอบงาน PHP หรือ Rails สำหรับทำตามแนวทางของเฟรมเวิร์กซึ่งโดยปกติแล้วเกี่ยวข้องกับการสร้างตัวแบบข้อมูลเป็นส่วนหนึ่งของรหัสแทนที่จะสร้างแอปพลิเคชันรอบตัวแบบข้อมูลซึ่งเป็นแบบดั้งเดิม วิธีการจัดการของ Microsoft

ดังนั้นเพื่อตอบคำถามฉันจะปฏิเสธไม่ได้ หากคุณมีข้อมูลที่มีอยู่แล้วและคุณกำลังสร้างแอปพลิเคชันเพื่อจัดการกับมัน Code First ไม่สมเหตุสมผลเท่าที่ควร อย่างไรก็ตาม, และฉันไม่ได้ใช้ EF มากเลยรหัสแรก EF, ดูเหมือนว่ามันเป็นวิธีการแบบคู่ที่หลวมกว่าซึ่งเป็นประโยชน์เสมอ สมมติว่าคุณสามารถใช้ Code First และยังคงชี้คลาสไปที่โมเดลข้อมูลที่มีอยู่ (แทนที่จะถูกบังคับให้สร้างโมเดล) แนวทาง Code First ยังสามารถช่วยในการเขียนโค้ดที่ถูกต้องนามธรรมและทดสอบได้โดยไม่ต้องใช้ "cruft" ทั้งหมดตามปกติ Entity Framework (เช่น metaclasses ที่สร้างขึ้น)

ฉันจะบอกว่าในโครงการขนาดใหญ่จริง ๆ รหัสแรกไม่สมเหตุสมผล

ในความเป็นจริงเมื่อโครงการมีขนาดใหญ่มากคุณมักจะแยกข้อกังวลออกมาอย่างเข้มงวด คุณไม่สามารถมีบุคคลเดียวกันที่เขียนรหัส C # ทำการออกแบบฐานข้อมูลเขียน HTML / CSS และออกแบบภาพใน Photoshop แต่การออกแบบฐานข้อมูลจะกระทำโดยผู้ดูแลระบบฐานข้อมูล (หรืออย่างน้อยก็โดยคนที่ทุ่มเทซึ่งรู้จักงานของเธอ)

เนื่องจากฐานข้อมูลได้รับการออกแบบโดยบุคคลที่คุ้นเคยกับฐานข้อมูล, SQL และเครื่องมือการจัดการและการออกแบบฐานข้อมูลจึงแปลกที่เห็นบุคคลนี้ใช้ Entity Framework

ยิ่งกว่านั้นฉันไม่แน่ใจว่า Entity Framework มีประสิทธิภาพเพียงพอที่จะออกแบบฐานข้อมูลได้อย่างถูกต้องหรือไม่ แล้วดัชนีล่ะ จำกัด ? ชม?

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