เป็นการออกแบบที่ไม่ดีหรือไม่? จะปรับปรุงได้อย่างไร?


9

ฉันเขียนสิ่งต่อไปนี้กลับมา แต่ฉันมาตรวจสอบเมื่อเร็ว ๆ นี้และตอนนี้ไม่คิดว่ามันจะเป็นการออกแบบที่ดี

การออกแบบสำหรับชั้นฐานข้อมูลแบบแยกส่วนโดยใช้ Entity Framework 4 มีวัตถุฐานข้อมูลเดียวซึ่งโหลดกรอบ (เอนทิตี้ของ) เอนทิตีกรอบบริบทจากไลบรารีภายนอกในตำแหน่งที่ระบุและอินสแตนซ์ของบริบทที่โหลดจะถูกเก็บไว้ในตารางแฮช ชื่อของพวกเขา (EG "ContentMgmtContext")

การติดต่อกับฐานข้อมูลทั้งหมดในระบบนี้ผ่านขั้นตอนการจัดเก็บ ในการโทรไปยังฐานข้อมูลลายเซ็นวิธีการสืบค้นจะมีลักษณะดังนี้

List<TReturn> Query<TReturn>(string Context, 
                             string Procedure, 
                             TransactionScope Scope, 
                             List<ObjectParameter> QueryParameters)

ต้นแบบนี้เป็นสิ่งที่ฉันชอบ อย่างไรก็ตามมีข้อเสียเปรียบที่สำคัญอย่างหนึ่งสำหรับวิธีนี้: when using the database layer, the code using it has to have a reference to the library in which the context is stored, in order to access the types returned by the stored procedures through Entity Framework.ในโมเดลวัตถุจากเลเยอร์ฐานข้อมูลจะถูกแปลเป็นวัตถุใหม่ที่มุมมองและตัวควบคุมใช้

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

ฉันจะปรับปรุงการออกแบบนี้ได้อย่างไร เกิดอะไรขึ้นกับมัน? หรือฉันถูกทาง?

คำตอบ:


6

ข้อจำกัดความรับผิดชอบ: ฉันไม่ได้ใช้เฟรมเวิร์กเอนทิตีและมีอคติอย่างมากต่อเฟรมเวิร์กตัวช่วยฐานข้อมูลใด ๆ

ดูเหมือนว่าคุณได้ทำเสื้อคลุม

ฉันสร้างความแตกต่างระหว่าง "wrapper" และ "layer" เลเยอร์เป็นสิ่งที่คุณอาจคอมไพล์เป็นของตัวเอง DLL / project / Jar / อะไรก็ตาม ชั้นการเข้าถึงข้อมูล แรปเปอร์เป็นคลาส "ตัวช่วย" ที่คุณใช้ภายใน DLL นั้น โดยมีวัตถุประสงค์เพื่อลดความซับซ้อนของอินเทอร์เฟซหรืออาจกำจัดการทำซ้ำ

ปัญหาเกี่ยวกับการทำให้อินเทอร์เฟซของการเข้าถึงฐานข้อมูลง่ายขึ้นนั้นปกติแล้วไม่ใช่เรื่องง่าย คุณสามารถทำซ้ำอินเตอร์เฟสของ ADO / JDBC / etc หรือคุณบังคับให้คนข้ามไป Wrappers มักจะทำสิ่งที่ไม่พึงประสงค์ทุกประเภท พวกเขาอาจปิดการเชื่อมต่อโดยอัตโนมัติเมื่อคุณต้องการเปิดเพื่อรองรับการทำธุรกรรม พวกเขามักจะเปิดการเชื่อมต่อไว้โดยไม่ตั้งใจหากคุณต้องส่งกระแสข้อมูลและใช้ภาษาที่รวบรวมขยะอย่างใดอย่างหนึ่ง เพื่อให้เต็มพลังของห้องสมุดหลังเสื้อคลุมของคุณคุณถูกบังคับให้ทำซ้ำ

ไลบรารี่เช่น ADO / JDBC เป็นอินเตอร์เฟสที่ยอดเยี่ยมอยู่แล้ว พวกเขาเป็นตัวอย่างที่ดีที่สุดของ OOP ที่ทำถูกต้อง ฉันต้องการใช้พวกเขามากกว่าเสื้อคลุม wizbang ดึงออกมาจากหมวกของเขา

อินเตอร์เฟสสไตล์ JDBC / ADO คลาสสิคเป็นที่รู้จักและเข้าใจกันดี เสื้อคลุมที่คุณดึงออกมาจากหมวกไม่ใช่

ต้องการลด "paramters.Add" ซ้ำซ้อนหรือไม่ ดูเป็นยาชื่อสามัญ หรือเพียงยอมรับว่าด้วยการพยายามลด "paramter.Add" จริง ๆ แล้วคุณเพียงแค่กด ".add" ไปยังเลเยอร์ของรหัสอื่น

BTW นี้เป็นคำถามที่ดี ฉันจะลงคะแนน 10 ครั้งถ้าทำได้

แก้ไข: แน่นอนรหัส JDBC จะถูกซ่อนอยู่ในชั้นการเข้าถึงข้อมูล


ฉันเห็นด้วยในความเข้าใจย้อนหลังว่านี่เป็นเสื้อคลุมรอบ EF 4 มากกว่าตัวของมันเอง แนวคิดเบื้องหลังคืออนุญาตให้มีการเชื่อมต่อฐานข้อมูลที่แตกต่างกัน (เช่นตัวแบบข้อมูลมาตรฐาน) เพื่อนำมาใช้ใหม่ในขณะที่ยังมีจุดเข้าเดียวสำหรับฐานข้อมูลหลาย ๆ อันแต่ละตัวมีลักษณะการใช้งานซ้ำ wrapper ฐานข้อมูลนี้รวบรวมในห้องสมุดแยกต่างหาก (พร้อมกับตรรกะทางธุรกิจอื่น ๆ ) คุณจะแนะนำให้ฉันเปลี่ยนการออกแบบเพื่อปรับปรุงได้อย่างไร
Andy Hunt

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