อะไรคือความแตกต่างระหว่าง Data Access Objects (DAO) และรูปแบบ Repository ฉันกำลังพัฒนาแอปพลิเคชันที่ใช้ Enterprise Java Beans (EJB3), Hibernate ORM เป็นโครงสร้างพื้นฐานและ Domain-Driven Design (DDD) และ Test-Driven Development (TDD) เป็นเทคนิคการออกแบบ
คำตอบ:
DAOเป็นนามธรรมของการติดตาข้อมูล
Repositoryเป็นนามธรรมของคอลเลกชันของวัตถุ
DAOจะถูกพิจารณาว่าใกล้กับฐานข้อมูลมากขึ้น
Repositoryจะได้รับการพิจารณาให้ใกล้เคียงกับโดเมนมากขึ้นเท่านั้น
Repositoryสามารถใช้งานได้โดยใช้DAOแต่คุณจะไม่ทำสิ่งตรงกันข้าม
นอกจากนี้Repositoryโดยทั่วไปแล้วอินเตอร์เฟสที่แคบกว่าก็คือ มันควรจะเป็นเพียงคอลเลกชันของวัตถุด้วยGet(id), , Find(ISpecification)Add(Entity)
วิธีการเช่นUpdateนี้เหมาะสมในการDAOแต่ไม่Repository- เมื่อใช้ a Repositoryการเปลี่ยนแปลงเอนทิตีมักจะถูกติดตามโดย UnitOfWork แยกต่างหาก
ดูเหมือนเป็นเรื่องธรรมดาที่จะเห็นการใช้งานที่เรียกว่า a Repositoryนั้นมีมากกว่าDAOและฉันคิดว่ามีความสับสนเกี่ยวกับความแตกต่างระหว่างพวกเขา
ตกลงคิดว่าฉันสามารถอธิบายได้ดีกว่าสิ่งที่ฉันได้แสดงความคิดเห็น :) โดยพื้นฐานแล้วคุณสามารถเห็นทั้งสองอย่างนี้เหมือนกันแม้ว่า DAO จะมีรูปแบบที่ยืดหยุ่นมากกว่า Repository หากคุณต้องการใช้ทั้งสองอย่างคุณจะใช้ Repository ใน DAO-s ของคุณ ฉันจะอธิบายแต่ละข้อด้านล่าง:
มันเป็นที่เก็บของวัตถุชนิดหนึ่ง - มันช่วยให้คุณสามารถค้นหาวัตถุชนิดใดชนิดหนึ่งโดยเฉพาะรวมถึงเก็บมัน โดยปกติจะจัดการกับวัตถุประเภทเดียวเท่านั้น เช่นAppleRepositoryจะช่วยให้คุณทำหรือAppleRepository.findAll(criteria) AppleRepository.save(juicyApple)โปรดทราบว่าที่เก็บกำลังใช้คำว่าโดเมนโมเดล (ไม่ใช่คำศัพท์ DB - ไม่มีอะไรเกี่ยวข้องกับวิธีการเก็บข้อมูลไว้ที่ใด)
พื้นที่เก็บข้อมูลส่วนใหญ่จะเก็บข้อมูลทั้งหมดในตารางเดียวกันในขณะที่รูปแบบไม่ต้องการ ข้อเท็จจริงที่ว่ามันจัดการข้อมูลชนิดเดียวเท่านั้นทำให้เชื่อมต่อแบบตรรกะกับตารางหลักหนึ่งตาราง (หากใช้สำหรับการคงอยู่ของฐานข้อมูล)
DAO เป็นคลาสที่ค้นหาข้อมูลให้คุณ (ส่วนใหญ่เป็นตัวค้นหา แต่โดยทั่วไปจะใช้เพื่อจัดเก็บข้อมูลด้วย) รูปแบบไม่ได้ จำกัด ให้คุณจัดเก็บข้อมูลประเภทเดียวกันดังนั้นคุณสามารถมี DAO ที่ตั้ง / เก็บวัตถุที่เกี่ยวข้อง
เช่นคุณสามารถมี UserDao ที่เปิดเผยวิธีการเช่น
Collection<Permission> findPermissionsForUser(String userId)
User findUser(String userId)
Collection<User> findUsersForPermission(Permission permission)ทั้งหมดที่เกี่ยวข้องกับผู้ใช้ (และความปลอดภัย) และสามารถระบุได้ภายใต้ DAO เดียวกัน นี่ไม่ใช่กรณีสำหรับพื้นที่เก็บข้อมูล
โปรดทราบว่ารูปแบบทั้งสองมีความหมายเหมือนกันจริง ๆ (พวกเขาเก็บข้อมูลและพวกเขาสรุปการเข้าถึงและพวกเขาทั้งคู่แสดงใกล้กับแบบจำลองโดเมนและแทบจะไม่มีการอ้างอิงฐานข้อมูล) แต่วิธีที่พวกเขาใช้อาจแตกต่างกันเล็กน้อย มีความยืดหยุ่นมากขึ้น / ทั่วไปเล็กน้อยในขณะที่ Repository นั้นมีความเฉพาะเจาะจงและ จำกัด เฉพาะประเภทมากขึ้นอีกเล็กน้อย
CarDescriptionที่มีเช่นlanguage_idเป็นกุญแจสำคัญในต่างประเทศ - เพื่อเรียกคืนว่าฉันควรทำสิ่งนี้: CarRepository.getAll(new Criteria(carOwner.id, language.id));ซึ่งจะให้รถยนต์ทุกคันของภาษาในภาษาเฉพาะ - เป็นวิธีที่เหมาะสมที่จะทำมัน ?
CarRepository.findByLanguageId(language.id)และคุณไม่จำเป็นต้องเขียนรหัสคุณเพียงแค่กำหนดส่วนต่อประสานด้วยวิธีการที่มีชื่อนั้นและ Spring Data ดูแลการสร้างการใช้งานคลาสเริ่มต้นสำหรับคุณ สิ่งที่สวยเรียบร้อย;)
findById) และคุณจะทำจริง สิ่งที่ Spring Data ทำก็คือมันจะพบอินเทอร์เฟซทั้งหมดที่คุณสร้างขึ้นซึ่งขยายอินเทอร์เฟซ Repository และสร้างคลาสให้คุณ คุณจะไม่เห็นคลาสเหล่านั้นและคุณจะไม่สามารถสร้างอินสแตนซ์ใหม่ได้ แต่คุณไม่จำเป็นต้องทำเช่นนั้นเพราะคุณสามารถป้อนอัตโนมัติอินเทอร์เฟซและให้ Spring ค้นหาวัตถุที่เก็บข้อมูลนั้น
รูปแบบ DAO และ Repository เป็นวิธีการใช้ Data Access Layer (DAL) ดังนั้นเริ่มต้นด้วย DAL ก่อน
แอปพลิเคชันเชิงวัตถุที่เข้าถึงฐานข้อมูลต้องมีตรรกะบางอย่างเพื่อจัดการการเข้าถึงฐานข้อมูล เพื่อที่จะรักษาความสะอาดของรหัสและโมดูลาร์ขอแนะนำให้แยกตรรกะการเข้าถึงฐานข้อมูลออกเป็นโมดูลแยกต่างหาก ในสถาปัตยกรรมแบบเลเยอร์โมดูลนี้คือ DAL
จนถึงตอนนี้เรายังไม่ได้พูดคุยเกี่ยวกับการใช้งานเฉพาะ: เพียงหลักการทั่วไปที่วางตรรกะการเข้าถึงฐานข้อมูลในโมดูลแยกต่างหาก
ตอนนี้เราจะใช้หลักการนี้ได้อย่างไร โดยเฉพาะอย่างยิ่งกับกรอบงานเช่นไฮเบอร์เนตคือรูปแบบ DAO
รูปแบบ DAO เป็นวิธีหนึ่งในการสร้าง DAL โดยทั่วไปนิติบุคคลแต่ละโดเมนจะมี DAO ของตนเอง ยกตัวอย่างเช่นUserและUserDao, AppointmentและAppointmentDaoฯลฯ ตัวอย่างของ DAO กับ Hibernate: http://gochev.blogspot.ca/2009/08/hibernate-generic-dao.html
จากนั้นรูปแบบ Repository คืออะไร? เช่นเดียวกับ DAO รูปแบบของที่เก็บก็เป็นวิธีที่ทำให้ DAL ประสบความสำเร็จเช่นกัน จุดหลักในรูปแบบ Repository คือจากมุมมองของลูกค้า / ผู้ใช้นั้นควรมีลักษณะหรือมีพฤติกรรมเป็นคอลเลกชัน Collection collection = new SomeCollection()อะไรคือความหมายโดยทำตัวเหมือนคอลเลกชันไม่ได้ว่ามันจะต้องมีการยกตัวอย่างเช่น แต่ก็หมายความว่าควรสนับสนุนการดำเนินการเช่นเพิ่มลบออกมี ฯลฯ นี่คือสาระสำคัญของรูปแบบ Repository
ในทางปฏิบัติเช่นในกรณีของการใช้ Hibernate รูปแบบที่เก็บจะรับรู้ด้วย DAO นั่นคืออินสแตนซ์ของ DAL ที่สามารถเป็นได้ทั้งอินสแตนซ์ของรูปแบบ DAO และรูปแบบ Repository
รูปแบบพื้นที่เก็บข้อมูลไม่จำเป็นต้องเป็นสิ่งที่หนึ่งสร้างบน DAO (ตามที่บางคนอาจแนะนำ) หาก DAO ได้รับการออกแบบด้วยอินเทอร์เฟซที่สนับสนุนการดำเนินการที่กล่าวถึงข้างต้นแสดงว่าเป็นอินสแตนซ์ของรูปแบบ Repository ลองคิดดูถ้า DAO มีชุดของการดำเนินการเหมือนคอลเลกชันอยู่แล้วอะไรคือสิ่งที่จำเป็นสำหรับเลเยอร์พิเศษด้านบนของมัน
ตรงไปตรงนี้ดูเหมือนความแตกต่างทางความหมายไม่ใช่ความแตกต่างทางเทคนิค วลี Data Access Object ไม่ได้อ้างอิงถึง "ฐานข้อมูล" เลย และถึงแม้ว่าคุณสามารถออกแบบให้เป็นฐานข้อมูลได้ แต่ฉันคิดว่าคนส่วนใหญ่จะพิจารณาที่จะทำข้อบกพร่องในการออกแบบ
วัตถุประสงค์ของ DAO คือการซ่อนรายละเอียดการใช้งานของกลไกการเข้าถึงข้อมูล รูปแบบพื้นที่เก็บข้อมูลแตกต่างกันอย่างไร เท่าที่ฉันสามารถบอกได้ การบอกว่า Repository นั้นแตกต่างจาก DAO เพราะคุณกำลังจัดการ / ส่งคืนชุดของวัตถุที่ไม่ถูกต้อง DAOs ยังสามารถส่งคืนคอลเลกชันของวัตถุ
ทุกอย่างที่ฉันได้อ่านเกี่ยวกับรูปแบบพื้นที่เก็บข้อมูลนั้นขึ้นอยู่กับความแตกต่างนี้: การออกแบบ DAO ไม่ดีเทียบกับการออกแบบ DAO ที่ดี (รูปแบบการออกแบบพื้นที่เก็บข้อมูล aka)
พื้นที่เก็บข้อมูลเป็นโดเมนที่เป็นนามธรรมมากกว่าคำที่เป็นส่วนหนึ่งของการออกแบบโดเมนขับเคลื่อนมันเป็นส่วนหนึ่งของการออกแบบโดเมนของคุณและภาษาทั่วไป DAO เป็นนามธรรมทางเทคนิคสำหรับเทคโนโลยีการเข้าถึงข้อมูลที่เก็บเป็นกังวลเฉพาะกับการจัดการข้อมูลที่มีอยู่และโรงงานเพื่อสร้าง ข้อมูล.
ตรวจสอบลิงก์เหล่านี้:
http://warren.mayocchi.com/2006/07/27/repository-or-dao/ http://fabiomaulo.blogspot.com/2009/09/repository-or-dao-repository.html
ความแตกต่างที่สำคัญคือที่เก็บจัดการการเข้าถึงรากรวมในการรวมในขณะที่ DAO จัดการการเข้าถึงเอนทิตี ดังนั้นจึงเป็นเรื่องธรรมดาที่ที่เก็บข้อมูลมอบหมายการมีอยู่จริงของรูทรวมให้กับ DAO นอกจากนี้เนื่องจากรากรวมจะต้องจัดการการเข้าถึงเอนทิตีอื่น ๆ ดังนั้นจึงอาจต้องมอบสิทธิ์การเข้าถึงนี้ให้แก่ DAO อื่น ๆ
DAO ให้สิ่งที่เป็นนามธรรมในไฟล์ฐานข้อมูล / ข้อมูลหรือกลไกการคงอยู่อื่น ๆ เพื่อให้สามารถจัดการเลเยอร์การคงอยู่ได้โดยไม่ทราบรายละเอียดการใช้งาน
โดยที่ในคลาส Repository คลาส DAO หลายคลาสสามารถใช้ภายในวิธีการ Repository เดียวเพื่อให้การดำเนินการเสร็จสิ้นจาก "มุมมองแอพ" ดังนั้นแทนที่จะใช้ DAO หลายตัวที่ Domain layer ให้ใช้ repository เพื่อทำให้เสร็จ Repository เป็นเลเยอร์ซึ่งอาจมีแอปพลิเคชั่นบางอย่างเช่น: หากข้อมูลมีอยู่ในแคชในหน่วยความจำให้ทำการดึงจากแคชมิฉะนั้นให้ดึงข้อมูลจากเครือข่ายและเก็บไว้ในแคชในหน่วยความจำสำหรับการเรียกใช้ครั้งต่อไป
พื้นที่เก็บข้อมูลไม่มีอะไรนอกจาก DAO ที่ออกแบบมาอย่างดี
ORM เป็นศูนย์กลางของตาราง แต่ไม่ใช่ DAO
ไม่จำเป็นต้องใช้ DAO หลายแห่งในที่เก็บเนื่องจาก DAO สามารถทำสิ่งเดียวกันกับที่เก็บ ORM / เอนทิตีหรือผู้ให้บริการ DAL ใด ๆ ไม่ว่าจะอยู่ที่ไหนและอย่างไรรถยังคงอยู่ 1 ตาราง 2 ตาราง n ตารางครึ่งตาราง a บริการเว็บตารางและบริการบนเว็บเป็นต้นบริการใช้ DAO / แหล่งเก็บข้อมูลหลายแห่ง
DAO ของฉันเองสมมติว่า CarDao จัดการกับ Car DTO เท่านั้นฉันหมายถึงใช้ Car DTO ในอินพุตเท่านั้นและส่งคืนรถ DTO หรือคอลเล็กชั่น DTO ในรถยนต์
ดังนั้นเช่นเดียวกับ Repository จริงๆแล้ว DAO นั้นเป็น IoC สำหรับตรรกะทางธุรกิจที่อนุญาตให้มีการใช้อินเทอร์เฟซการติดตาไม่ถูกข่มขู่ด้วยกลยุทธ์หรือมรดกที่ติดตัว DAO ทั้งแค็ปซูลกลยุทธ์การคงอยู่และจัดเตรียมอินเทอร์เฟซการสืบทอดโดเมนที่เกี่ยวข้อง พื้นที่เก็บข้อมูลเป็นเพียงคำอีกคำหนึ่งสำหรับผู้ที่ไม่เข้าใจว่า DAO จริงๆแล้วคืออะไร
ลองค้นหาว่า DAO หรือรูปแบบพื้นที่เก็บข้อมูลสามารถใช้ได้กับสถานการณ์ต่อไปนี้มากที่สุด: ลองจินตนาการว่าคุณต้องการให้ API การเข้าถึงข้อมูลที่สม่ำเสมอสำหรับกลไกถาวรกับแหล่งข้อมูลประเภทต่างๆเช่น RDBMS, LDAP, OODB, ที่เก็บ XML และ ไฟล์แบน
โปรดอ้างถึงลิงก์ต่อไปนี้เช่นกันหากสนใจ:
http://www.codeinsanity.com/2008/08/repository-pattern.html
http://blog.fedecarg.com/2009/03/15/domain-driven-design-the-repository/
http://devlicio.us/blogs/casey/archive/2009/02/20/ddd-the-repository-pattern.aspx
ในประโยคที่ง่ายมาก: ความแตกต่างที่สำคัญคือที่เก็บเป็นตัวแทนของคอลเลกชันในขณะที่ DAO อยู่ใกล้กับฐานข้อมูลมากขึ้นมักจะเป็นศูนย์กลางของตาราง
ในเฟรมเวิร์กสปริงมีคำอธิบายประกอบที่เรียกว่าที่เก็บและในคำอธิบายของคำอธิบายประกอบนี้มีข้อมูลที่เป็นประโยชน์เกี่ยวกับที่เก็บซึ่งฉันคิดว่ามันมีประโยชน์สำหรับการสนทนานี้
บ่งชี้ว่าคลาสที่ทำหมายเหตุประกอบไว้เป็น "Repository" ซึ่ง แต่เดิมกำหนดโดย Domain-Driven Design (Evans, 2003) เป็น "กลไกสำหรับการห่อหุ้มหน่วยความจำการดึงและพฤติกรรมการค้นหาซึ่งจำลองชุดของวัตถุ"
ทีมที่ใช้รูปแบบ Java EE แบบดั้งเดิมเช่น "Data Access Object" อาจนำไปใช้กับคลาส DAO ได้เช่นกัน แต่ควรระมัดระวังในการทำความเข้าใจความแตกต่างระหว่าง Data Access Object และที่เก็บแบบ DDD ก่อนที่จะทำเช่นนั้น คำอธิบายประกอบนี้เป็นกฎตายตัวทั่วไปและแต่ละทีมอาจ จำกัด ความหมายและใช้ตามความเหมาะสม
คลาสที่มีคำอธิบายประกอบจะมีสิทธิ์ใช้งานการแปล Spring DataAccessException เมื่อใช้ร่วมกับ PersistenceExceptionTranslationPostProcessor คลาสที่มีการเพิ่มความคิดเห็นนั้นจะได้รับการอธิบายให้ชัดเจนถึงบทบาทของมันในสถาปัตยกรรมแอปพลิเคชันโดยรวมเพื่อวัตถุประสงค์ในการใช้เครื่องมือ, แง่มุมและอื่น ๆ
IRepositoryอินเตอร์เฟสของคุณอย่างแท้จริง คุณต้องการให้ที่เก็บของคุณใช้ DAO ในการนำไปใช้ โปรดจำไว้ว่า DAO จะเป็นวัตถุต่อตารางในขณะที่พื้นที่เก็บข้อมูลมักจะต้องใช้หลาย DAO เพื่อสร้างเอนทิตีเดียว หากคุณพบว่าไม่ใช่ในกรณีของที่เก็บและเอนทิตีของคุณเพียงแค่ต้องเข้าถึงตารางเดียวนั่นหมายความว่าคุณมีแนวโน้มที่จะสร้างโดเมนแอนติโนมิก