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


21

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

เรากำลังออกแบบ DAL ของเราใหม่เพื่อใช้ Entity Framework และคำแนะนำส่วนใหญ่ที่ฉันเคยเห็นแนะนำให้ใช้รูปแบบ Repository อย่างไรก็ตามไม่มีตัวอย่างใดที่จัดการกับตัวแบบวัตถุที่ซับซ้อนได้ การใช้งานบางอย่างที่ฉันพบแนะนำให้ใช้ repository ต่อเอนทิตี ดูเหมือนว่าไร้สาระและไม่สามารถบำรุงรักษาได้สำหรับรุ่นที่มีขนาดใหญ่และซับซ้อน

จำเป็นหรือไม่ที่จะสร้าง UnitOfWork สำหรับแต่ละการดำเนินการและที่เก็บสำหรับแต่ละเอนทิตี ฉันสามารถจบลงด้วยชั้นเรียนหลายพันชั้น ฉันรู้ว่าสิ่งนี้ไม่สมเหตุสมผล แต่ฉันได้พบแนวทางเล็กน้อยในการใช้ Repository, Unit of Work และ Entity Framework ผ่านโมเดลที่ซับซ้อนและแอปพลิเคชันทางธุรกิจที่สมจริง

คำตอบ:


6

ขั้นแรกคุณจะดำเนินการผ่านทุกเอนทิตีที่คุณมีและถามตัวคุณเอง:

มันสมเหตุสมผลไหมที่จะสานต่อเอนทิตีนี้เพียงลำพัง?

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

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


ลิงค์ที่ดี! ฉันกำลังตรวจสอบมัน
Eric Falsken

ลิงก์ของคุณ (และคำตอบ) มีประโยชน์มากที่สุดแม้ว่าฉันจะไม่ได้ใช้รูปแบบที่มีให้ ฉันลงเอยด้วยการใช้คลาส wrapper ที่ proxied วิธีการเพิ่ม / แนบ / ลบ / SaveChanges เพื่อทำงานเป็นพื้นที่เก็บข้อมูลทั่วไปแล้วเพิ่มวิธีการ Query / QuerySingle / QueryAll ที่ยอมรับคลาสแบบสอบถามแบบกำหนดเองเพื่อระงับการใช้แบบสอบถามของฉัน สิ่งนี้ได้ผลเป็นอย่างดีเพื่อให้ฉันสามารถทำทั้งแบบสอบถาม LINQ และ T-SQL โดยไม่ต้องเกี่ยวข้องกับ EF โดยตรง
Eric Falsken

Entity Framework, กับการใช้งานของการทำธุรกรรมเป็นแล้วการดำเนินการของหน่วยของรูปแบบการทำงาน
เกร็ก Burghardt

1
ลิงค์ตาย ...
Newtopian

3

บางทีคุณอาจจะมีลักษณะที่โดเมนที่ขับเคลื่อนด้วยการออกแบบ แนะนำให้จัดกลุ่มวัตถุของคุณใน Aggregates และสร้างที่เก็บสำหรับเอนทิตี Root ของแต่ละ Aggregate เท่านั้น มันเป็นวิธีที่ดีในการสั่งซื้อโมเดลวัตถุขนาดใหญ่ที่ซับซ้อน

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


0

คุณพบพื้นฐานทางทฤษฎีใดบ้างสำหรับการออกแบบฐานข้อมูล "รูปแบบพื้นที่เก็บข้อมูล" ฉันคาดเดาไม่ได้ มันเป็นเลเยอร์ของความซับซ้อนที่วางอยู่บนสถานที่ปลอม: "เลเยอร์คงอยู่" เป็นสิ่งที่คุณต้องแยกออกจาก จากสิ่งที่ฉันสามารถบอกได้มันเล่นกับการเขียนโปรแกรมอย่างกว้างขวางไม่รู้หลักการออกแบบเชิงสัมพันธ์และ panders ถึงศูนย์กลางของการออกแบบ OO ของแอปพลิเคชัน แต่มันไม่ได้พิสูจน์ให้เห็นถึงการดำรงอยู่ของเหตุผลเหตุผลทางทฤษฎีเพียงอย่างเดียว

One True Path to to database ออกแบบไม่เปลี่ยนแปลงใน 30 ปี: วิเคราะห์ข้อมูล ค้นหากุญแจและข้อ จำกัด และความสัมพันธ์แบบตัวต่อตัว ออกแบบตารางของคุณตามแบบฟอร์มปกติของ Boyce-Codd ใช้มุมมองและขั้นตอนการจัดเก็บเพื่ออำนวยความสะดวกในการเข้าถึงข้อมูล

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

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

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

ตัวอย่างเช่นคุณพิจารณาไตร่ตรองหน่วยงานในฐานข้อมูล (เช่นฉันคิดว่าเป็นตารางหรือตาราง) หน่วยของการทำงานเป็นตัวในการให้บริการของ DBMS นี้: begin transactionฐานข้อมูลการปรับปรุง ... commit transaction... ไม่มีสิ่งใดที่จะเป็นโมเดลนอกจากการแม็พคลาสของคุณกับตารางฐานข้อมูลใน SQL

คำถามของคุณโพสต์เมื่อ 4 ปีที่ผ่านมา ฉันกำลังตอบเพราะเป็น "อัปเดต" ไม่ทางใดก็ทางหนึ่งซึ่งบ่งบอกว่ามันยังเป็นที่สนใจของใครบางคน ฉันหวังว่าคำตอบของฉันจะกระตุ้นให้ผู้อ่านใช้ทฤษฎีเชิงสัมพันธ์ขั้นพื้นฐานกับปัญหาแทนที่จะใช้วิธีแก้ปัญหาที่ไม่มีจุดหมาย

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.