พวกเดียวกันหรือเปล่า? เพิ่งดูบทช่วยสอนหน้าร้านของ Rob Conneryเสร็จแล้วและดูเหมือนว่าพวกเขาจะคล้าย ๆ กัน ฉันหมายถึงเมื่อฉันใช้อ็อบเจกต์ DAL ฉันมีเมธอด GetStuff, Add / Delete และอื่น ๆ และฉันมักจะเขียนอินเทอร์เฟซก่อนเพื่อที่ฉันจะสามารถเปลี่ยน db ในภายหลังได้
ฉันสับสนหรือเปล่า?
คำตอบ:
คุณไม่ใช่คนที่ทำให้สับสน :-)
ฉันคิดว่าคำตอบของคำถามขึ้นอยู่กับว่าคุณอยากเป็นคนเจ้าระเบียบมากแค่ไหน
หากคุณต้องการมุมมอง DDD ที่เข้มงวดนั่นจะนำคุณไปสู่เส้นทางเดียว หากคุณมองที่ที่เก็บเป็นรูปแบบที่ช่วยให้เราสร้างมาตรฐานอินเทอร์เฟซของเลเยอร์ที่แยกระหว่างบริการและฐานข้อมูลมันจะนำคุณไปสู่อีกขั้นหนึ่ง
ที่เก็บจากมุมมองของฉันเป็นเพียงชั้นการเข้าถึงข้อมูลที่ระบุไว้อย่างชัดเจนหรืออีกนัยหนึ่งคือวิธีมาตรฐานในการใช้ Data Access Layer ของคุณ มีความแตกต่างบางประการระหว่างการใช้งานที่เก็บที่แตกต่างกัน แต่แนวคิดก็เหมือนกัน
บางคนจะใส่ข้อ จำกัด DDD ในที่เก็บมากขึ้นในขณะที่คนอื่น ๆ จะใช้ที่เก็บเป็นสื่อกลางที่สะดวกระหว่างฐานข้อมูลและชั้นบริการ ที่เก็บเช่น DAL จะแยกชั้นบริการออกจากข้อมูลเฉพาะการเข้าถึงข้อมูล
ปัญหาการใช้งานอย่างหนึ่งที่ดูเหมือนจะทำให้แตกต่างกันคือที่เก็บข้อมูลมักถูกสร้างขึ้นด้วยวิธีการที่ใช้ข้อกำหนด ที่เก็บจะส่งคืนข้อมูลที่ตรงตามข้อกำหนดนั้น DAL แบบดั้งเดิมส่วนใหญ่ที่ฉันเคยเห็นจะมีชุดวิธีการที่ใหญ่กว่าซึ่งวิธีนี้จะใช้พารามิเตอร์จำนวนเท่าใดก็ได้ แม้ว่าสิ่งนี้อาจฟังดูแตกต่างเล็กน้อย แต่ก็เป็นปัญหาใหญ่เมื่อคุณเข้าสู่อาณาจักรของ Linq และ Expressions อินเทอร์เฟซที่เก็บเริ่มต้นของเรามีลักษณะดังนี้:
public interface IRepository : IDisposable
{
T[] GetAll<T>();
T[] GetAll<T>(Expression<Func<T, bool>> filter);
T GetSingle<T>(Expression<Func<T, bool>> filter);
T GetSingle<T>(Expression<Func<T, bool>> filter, List<Expression<Func<T, object>>> subSelectors);
void Delete<T>(T entity);
void Add<T>(T entity);
int SaveChanges();
DbTransaction BeginTransaction();
}
นี่คือ DAL หรือที่เก็บ? ในกรณีนี้ฉันเดาว่ามันทั้งสองอย่าง
คิม
ที่เก็บเป็นรูปแบบที่สามารถนำไปใช้ได้หลายวิธีในขณะที่ชั้นการเข้าถึงข้อมูลมีหน้าที่ที่ชัดเจนมาก: DAL ต้องรู้วิธีเชื่อมต่อกับที่เก็บข้อมูลของคุณเพื่อดำเนินการ CRUD
ที่เก็บอาจเป็น DAL แต่ยังสามารถนั่งอยู่หน้า DAL และทำหน้าที่เป็นสะพานเชื่อมระหว่างชั้นออบเจ็กต์ทางธุรกิจและชั้นข้อมูล การนำไปใช้จะแตกต่างกันไปในแต่ละโครงการ
ความแตกต่างอย่างมากประการหนึ่งคือ DAO เป็นวิธีทั่วไปในการจัดการกับความคงอยู่ของเอนทิตีใด ๆ ในโดเมนของคุณ ในทางกลับกันที่เก็บจะเกี่ยวข้องกับรากรวมเท่านั้น
ฉันกำลังมองหาคำตอบสำหรับคำถามที่คล้ายกันและเห็นด้วยกับคำตอบสองอันดับสูงสุด พยายามชี้แจงสิ่งนี้ด้วยตัวเองฉันพบว่าหาก Specifications ซึ่งไปพร้อมกันกับรูปแบบพื้นที่เก็บข้อมูลถูกนำไปใช้ในฐานะสมาชิกชั้นหนึ่งของโมเดลโดเมนฉันก็จะทำได้
ฉันอาจจะไปไกลแล้วและระบุว่าเว้นแต่จะใช้รูปแบบพื้นที่เก็บข้อมูลร่วมกับรูปแบบข้อมูลจำเพาะไม่ใช่ "Repository" แต่เป็น DAL ตัวอย่างที่สร้างขึ้นในรหัสหลอก:
specification100 = new AccountHasMoreOrdersThan(100)
specification200 = new AccountHasMoreOrdersThan(200)
assert that specification200.isSpecialCaseOf(specification100)
specificationAge = new AccountIsOlderThan('2000-01-01')
combinedSpec = new CompositeSpecification(
SpecificationOperator.And, specification200, specificationAge)
for each account in Repository<Account>.GetAllSatisfying(combinedSpec)
assert that account.Created < '2000-01-01'
assert that account.Orders.Count > 200
ดูรายละเอียดของ Fowler's Specification Essay (นั่นคือสิ่งที่ฉันอ้างอิงจากข้างต้น)
DAL จะมีวิธีการพิเศษเช่น
IoCManager.InstanceFor<IAccountDAO>()
.GetAccountsWithAtLeastOrdersAndCreatedBefore(200, '2000-01-01')
คุณสามารถดูได้ว่าสิ่งนี้จะกลายเป็นเรื่องยุ่งยากได้อย่างไรโดยเฉพาะอย่างยิ่งเมื่อคุณต้องกำหนดอินเทอร์เฟซ DAL / DAO แต่ละรายการด้วยวิธีการนี้และใช้วิธีการสืบค้น DAL
ใน. NET การสืบค้น LINQ อาจเป็นวิธีหนึ่งในการปรับใช้ข้อกำหนด แต่การรวมข้อมูลจำเพาะ (นิพจน์) อาจไม่ราบรื่นเท่ากับโซลูชันที่ผลิตเองที่บ้าน แนวคิดบางประการที่อธิบายไว้ในคำถาม SOนี้
ความเห็นส่วนตัวของฉันก็คือว่ามันคือทั้งหมดที่เกี่ยวกับการทำแผนที่ดู: http://www.martinfowler.com/eaaCatalog/repository.html ดังนั้นเอาต์พุต / อินพุตจากที่เก็บจึงเป็นอ็อบเจ็กต์โดเมนซึ่งบน DAL อาจเป็นอะไรก็ได้ สำหรับฉันนั่นคือการเพิ่ม / ข้อ จำกัด ที่สำคัญเนื่องจากคุณสามารถเพิ่มการใช้งานที่เก็บสำหรับฐานข้อมูล / บริการ / อะไรก็ตามที่มีเลย์เอาต์ที่แตกต่างกันและคุณมีจุดที่ชัดเจนในการทำแผนที่ หากคุณไม่ได้ใช้ข้อ จำกัด นั้นและมีการทำแผนที่ที่อื่นการมีวิธีต่างๆในการแสดงข้อมูลอาจส่งผลต่อรหัสในที่ที่ไม่ควรเปลี่ยนแปลง
ทุกอย่างเกี่ยวกับการตีความและบริบท อาจจะคล้ายกันมากหรือแตกต่างกันมาก แต่ตราบใดที่วิธีแก้ปัญหาได้ผลสิ่งที่อยู่ในชื่อ
ในที่เก็บโลกภายนอก (เช่นรหัสไคลเอนต์) จะเหมือนกับ DAL ยกเว้น:
(1) วิธีการแทรก / อัปเดต / ลบถูก จำกัด ให้มีวัตถุที่เก็บข้อมูลเป็นพารามิเตอร์
(2) สำหรับการดำเนินการอ่านอาจใช้ข้อกำหนดง่ายๆเช่น DAL (เช่น GetByPK) หรือข้อกำหนดขั้นสูง
ภายในทำงานร่วมกับ Data Mapper Layer (เช่นบริบทของกรอบงานเอนทิตีเป็นต้น) เพื่อดำเนินการ CRUD จริง
รูปแบบพื้นที่เก็บข้อมูลไม่ได้หมายถึงอะไร: -
นอกจากนี้ฉันเคยเห็นผู้คนมักสับสนที่จะมีวิธีการบันทึกแยกต่างหากเป็นการนำตัวอย่างรูปแบบพื้นที่เก็บข้อมูลนอกเหนือจากวิธีการแทรก / อัปเดต / ลบซึ่งยอมรับการเปลี่ยนแปลงในหน่วยความจำทั้งหมดที่ดำเนินการโดยวิธีการแทรก / อัปเดต / ลบไปยังฐานข้อมูล เราสามารถมีเมธอด Save ได้อย่างแน่นอนในที่เก็บ แต่นั่นไม่ใช่ความรับผิดชอบของที่เก็บในการแยก CUD ในหน่วยความจำ (สร้างอัปเดตลบ) และวิธีการคงอยู่ (ซึ่งดำเนินการเขียน / เปลี่ยนแปลงจริงในฐานข้อมูล) แต่ ความรับผิดชอบของรูปแบบหน่วยงาน
หวังว่านี่จะช่วยได้!
Repository เป็นรูปแบบซึ่งเป็นวิธีการนำสิ่งต่าง ๆ ไปใช้ในรูปแบบมาตรฐานเพื่อนำโค้ดกลับมาใช้ใหม่เท่าที่เราทำได้
ข้อดีของการใช้รูปแบบพื้นที่เก็บข้อมูลคือการจำลองชั้นการเข้าถึงข้อมูลของคุณเพื่อให้คุณสามารถทดสอบรหัสชั้นธุรกิจของคุณได้โดยไม่ต้องเรียกรหัส DAL มีข้อดีอื่น ๆ แต่ดูเหมือนว่าจะมีความสำคัญกับฉันมาก
จากสิ่งที่ฉันเข้าใจพวกเขาอาจหมายถึงสิ่งเดียวกันโดยพื้นฐาน - แต่การตั้งชื่อจะแตกต่างกันไปตามบริบท
ตัวอย่างเช่นคุณอาจมีคลาส Dal / Dao ที่ใช้อินเทอร์เฟซ IRepository
Dal / Dao เป็นคำศัพท์ชั้นข้อมูล ระดับที่สูงขึ้นของแอปพลิเคชันของคุณจะคิดในแง่ของที่เก็บ
ดังนั้นในกรณีส่วนใหญ่ (ง่าย ๆ ) DAO คือการนำ Repository มาใช้?
เท่าที่ฉันเข้าใจดูเหมือนว่า DAO จะเกี่ยวข้องกับการเข้าถึงฐานข้อมูลอย่างแม่นยำ (CRUD - ไม่มีการเลือกแม้ว่า?!) ในขณะที่ Repository ช่วยให้คุณสามารถสรุปการเข้าถึงข้อมูลทั้งหมดได้โดยอาจเป็นส่วนหน้าของ DAO หลายตัว (อาจเป็นแหล่งข้อมูลที่แตกต่างกัน)
ฉันมาถูกทางหรือเปล่า
อาจโต้แย้งได้ว่า "ที่เก็บ" เป็นคลาสเฉพาะและ "DAL" คือเลเยอร์ทั้งหมดที่ประกอบด้วยที่เก็บ DTO คลาสยูทิลิตี้และสิ่งอื่น ๆ ที่จำเป็น