สถาปัตยกรรมที่พูดแล้ว abstraction layer ของฐานข้อมูลเช่น Entity Framework ของ Microsoft ทำให้ความต้องการ Data Access Layer แยกจากกันหรือไม่?

วิธีที่มันเป็น

เป็นเวลาหลายปีที่ฉันจัดระเบียบโซลูชันซอฟต์แวร์ของฉันเช่น:

Data Access Layer (DAL) เป็นนามธรรมธุรกิจของการเข้าถึงข้อมูล
Business Logic Layer (BLL) เพื่อใช้กฎธุรกิจกับชุดข้อมูลจัดการการตรวจสอบความถูกต้อง ฯลฯ
Utilities (Util) ซึ่งเป็นเพียงไลบรารีของวิธีการใช้งานทั่วไปที่ฉันสร้างขึ้นเมื่อเวลาผ่านไป
Presentation Layer ซึ่งแน่นอนว่าอาจเป็นเว็บเดสก์ท็อปมือถือหรืออะไรก็ตาม

วิธีที่มันเป็นตอนนี้

สำหรับสี่ปีที่ผ่านมาหรือดังนั้นฉันใช้ Entity Framework ของ Microsoft (ฉันมีอำนาจเหนือกว่า. dev dev) และฉันพบว่าการมี DAL กลายเป็นเรื่องยุ่งยากมากกว่าการทำความสะอาดเพราะบัญชี Entity Framework ได้ทำไปแล้ว งานที่ DAL ของฉันเคยทำ: มันสรุปธุรกิจของการรัน CRUDs กับฐานข้อมูล

ดังนั้นฉันมักจะจบลงด้วย DAL ที่มีคอลเลกชันของวิธีการเช่นนี้:

public static IQueryable<SomeObject> GetObjects(){
    var db = new myDatabaseContext();
    return db.SomeObjectTable;
}

จากนั้นใน BLL วิธีนี้จะใช้เช่น:

public static List<SomeObject> GetMyObjects(int myId){
    return DAL.GetObjects.Where(ob => op.accountId == myId).ToList();
}

นี่เป็นตัวอย่างที่ง่ายอย่างแน่นอนเนื่องจากโดยทั่วไปแล้ว BLL จะมีการใช้ตรรกะอีกหลายบรรทัด แต่ดูเหมือนว่าจะมากเกินไปเล็กน้อยในการรักษา DAL สำหรับขอบเขตที่ จำกัด

จะเป็นการดีกว่าหรือไม่ที่จะละทิ้ง DAL และเพียงเขียนวิธี BLL ของฉันเช่น:

public static List<SomeObject> GetMyObjects(int myId){
    var db = new myDatabaseContext();
    return db.SomeObjectTable.Where(ob => op.accountId == myId).ToList();
}

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

ความคิดใด ๆ ที่ชื่นชม

ปรับปรุง

ฉันทามติดูเหมือนว่า DAL แยกต่างหากไม่จำเป็น แต่ (ทำให้การอนุมานของฉันเองที่นี่) เป็นความคิดที่ดีที่จะหลีกเลี่ยงการล็อคผู้ขายตัวอย่างเช่นถ้าฉันมี DAL ที่ทำให้นามธรรมเรียก EF ดังที่แสดงไว้ด้านบนถ้าฉัน เคยเปลี่ยนไปใช้ผู้ขายรายอื่นฉันไม่จำเป็นต้องเขียน BLL ใหม่ เฉพาะแบบสอบถามพื้นฐานเหล่านั้นใน DAL เท่านั้นที่จะต้องมีการเขียนใหม่ ต้องบอกว่าฉันพบว่ามันยากที่จะจินตนาการสถานการณ์ที่จะเกิดขึ้น ฉันสามารถสร้างรูปแบบ Oracle ของฐานข้อมูล Oracle, MSSQL ได้แล้วฉันค่อนข้างแน่ใจว่า MySql นั้นเป็นไปได้เช่นกัน (??) ดังนั้นฉันไม่แน่ใจว่ารหัสพิเศษจะให้ ROI ที่คุ้มค่าหรือไม่

— แมตต์ Cashatt
แหล่งที่มา

a / ชั้นการเข้าถึงข้อมูลของคุณแตกต่างจาก EF อย่างไร EF ไม่ใช่ data access layer หรือไม่ เหตุผลเดียวที่ฉันเห็นได้ว่าคุณให้ความสำคัญกับตรรกะทางธุรกิจของคุณและ EF คือการทำให้การทดสอบง่ายขึ้นและหลีกเลี่ยงการล็อคผู้ขาย

— Marjan Venema

นั่นคือประเด็นของฉัน - ไม่มีความแตกต่างในมุมมองของฉัน แต่ฉันกำลังมองหาจุดเคาน์เตอร์ ขอบคุณ

— Matt Cashatt

โดยส่วนตัวแล้วฉันไม่เห็นเหตุผลที่จะสร้าง DAL แยกเนื่องจาก EF / NHibernate เป็นชั้นการเข้าถึงข้อมูลในตัวเอง ดังที่ Marjan พูดถึงด้วย EF คุณสามารถพิจารณาได้หากคุณเห็นผู้ขายฐานข้อมูลเปลี่ยนแปลงใน NHibernate คุณสามารถสลับไดรเวอร์ในหนึ่งบรรทัดของรหัส (แม้แต่ไดรเวอร์ SQLite สำหรับการทดสอบในหน่วยความจำ) ดังนั้นมันจะเป็นรหัสที่ไม่จำเป็น (IMO)

— Patryk Ćwiek

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

— Andyz Smith

อีกครั้งปรับปรุง: ชั้นพิเศษนี้สามารถทำให้ unittests ของ busineslayer ง่ายมากเพราะเยาะเย้ย / stubbing / แกล้งทำของGetMyObjects(int myId)ง่ายกว่าเยาะเย้ย / stubbing / GetObjects.Where(ob => op.accountId == myId).ToList()แกล้งทำของ

— k3b

คำตอบ:

ไม่แน่ใจว่านี่เป็นคำตอบที่คุณต้องการหรือไม่ แต่นี่จะไป

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

เรายังคงเรียกมันว่า "Data Access Layer" เนื่องจากมีชุดประกอบทั้งหมดเพื่อรองรับ ORM ของเรา

ฉันควรทราบว่าแอปหลักของเราอ้างอิง 5 ฐานข้อมูลมีประมาณ 4-500 วัตถุ / การแมปโดเมนและสคีมาต่างๆ ดังนั้นการตั้งค่านี้เหมาะสมสำหรับเรา บางทีสำหรับแอพเล็ก ๆ คุณอาจจะข้ามแอสเซมบลีนี้ แต่ .. ฉันเป็นผู้ดูดรหัสที่เป็นระเบียบและอาจจะทำมันต่อไป :)

— ไซมอนเฮด
แหล่งที่มา

ฉันดู EF และ DAL เป็นส่วนประกอบแยกต่างหากในระบบ Enterprise Data Access Layer เป็นนามธรรมที่บริการอื่น ๆ ใช้เพื่อดำเนินการเก็บข้อมูลและการจัดการ โดยทั่วไป Entity Frameworks จะสร้าง API ที่ดีในการสืบค้นอัปเดตลบและแทรกอย่างไรก็ตามที่แกนหลักพวกเขายังต้องการการเชื่อมต่อโดยตรงกับแหล่งข้อมูลส่วนหลัง ดังนั้นการกำหนดเส้นทางหรือไฟร์วอลล์ทุกประเภทจะหยุดการทำงานของ EF ดังนั้นคุณต้องสร้างส่วนประกอบสื่อกลางของ EF

นี่คือตัวอย่างระดับสูงที่แสดงว่า DAL และ EF เหมาะสมกับอะไร:

-------------    -------                                    ----------------    ------
| Service A | -> | DAL | -> { LOCAL / LAN / WAN ACCESS } -> | DAL BACK-END | -> | EF |
-------------    -------                                    ----------------    ------

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

การออกแบบนี้แนะนำ abstractions รั่วไหลบางส่วน ดังนั้นควรพิจารณาเป็นกรณีไป

คำถามที่จะถาม:

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

— Andrew T Finnell
แหล่งที่มา

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

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

ในทำนองเดียวกัน EF ภายใน DAL อาจทำการจำลองการเข้าถึงข้อมูลสำหรับหน่วยรหัส BLL ของคุณเพื่อทดสอบที่ตรงไปตรงมามากขึ้น

ดังนั้นมุมมองของฉันคือ EF (หรือ ORMS อื่น ๆ ) ไม่จำเป็นต้องเป็นโมฆะสำหรับชั้นการเข้าถึงข้อมูล

— อเล็กซ์สีขาว
แหล่งที่มา