Download as PDF, PPTX
Uploaded byHatim Hakeel
Repository and Unit Of Work Design Patterns
The document discusses repository and unit of work design patterns, emphasizing their roles in mediating between domain and data layers for improved abstraction in data handling. It distinguishes between data access objects (DAOs) and repositories, highlighting the latter's ability to work with aggregations of entities. The unit of work pattern is presented as a method for managing transactions and synchronizing in-memory data with the database, alongside architectural considerations for implementing these patterns in applications using frameworks like Entity Framework and ASP.NET MVC.
More Related Content
![[Final] ReactJS presentation](https://cdn.slidesharecdn.com/ss_thumbnails/65cfd4f9-740f-4f41-b769-b496b6e60802-170119143904-thumbnail.jpg?width=640&height=640&fit=bounds)
Similar to Repository and Unit Of Work Design Patterns
Repository and Unit Of Work Design Patterns
- 1. Repository and Unitof Work Design Patterns 29th October 2014 Presented By: Hatim Hakeel
- 2.
- 3. Repository Object-Relational MetadataMapping Patterns • Metadata Mapping • Query Object • Repository Repository – Mediates between the domain and data mapping layers using a collection-like interface for accessing domain objects 10/29/2014 Page 3
- 4. What about DAOs? • A Data Access Object doesn’t hide to the Data Access Layer that it is accessing a data table, unlike a Repository. • A DAO typically has a 1:1 map with a data store table or entity-set. • A Repository acts at a higher level of abstraction working with aggregations of business entities. 10/29/2014 Page 4
- 5. Why use Repositories? • Abstraction layer between Business Logic Layer and Data Access Layer. • Insulates application (Controller) from data store changes. • Facilitates automated Unit Testing, Test Driven Development. How ? • Easy to create mock repositories using in-memory domain object collections as a data store. But it’s difficult to mock entities similarly. 10/29/2014 Page 5
- 6. UoW Object-Relational BehaviorPatterns • Unit of Work • Identity Map • Lazy Load UoW – Maintains a list of objects affected by a business transaction and coordinates the writing out of changes and the resolution of concurrency problems 10/29/2014 Page 6
- 7. Why use UoW? • Keeps track of manipulated objects in order to synchronize in-memory data with the data store. • Provides a single transaction for multiple queries. • The UoW commits the transaction. • If the commit fails, rollback. • Single commit call on the database. • All object tracking information is centralized. • Provides a firm means for complex scenarios like handling business transactions that span several system transactions using Optimistic Offline Lock and Pessimistic Offline Lock. 10/29/2014 Page 7
- 8. Entity Framework 5and ASP.NET MVC 4 and previous versions… • Repository classes with a UoW class. • Repository classes without a UoW class. • Single Repository. • A Repository class per Entity. 10/29/2014 Page 8
- 9. The Overall BiggerPicture 10/29/2014 Page 9
- 10. A possible projectstructure 10/29/2014 Page 10
- 11.
- 12. UnitofWork.cs i 10/29/2014Page 12
- 13. GenericRepository<TEntity> Getters ii 10/29/2014 Page 13
- 14. Persist DbContext changesand clean up resources iii 10/29/2014 Page 14
- 15.
- 16. GenericRepository<TEntity> constructor i 10/29/2014 Page 16
- 17. IEnumerable<TEnitity> Get(…) ii 10/29/2014 Page 17
- 18. Remaining CRUD method implementations iii 10/29/2014 Page 18
- 19. EF DbContext implementer 10/29/2014 Page 19
- 20. How does thearchitectural wiring come live in the controller ? 10/29/2014 Page 20
- 21. Sample Edit, Get(…)calls 10/29/2014 Page 21
- 22. Entity Framework 6and ASP.NET MVC 5 From http://goo.gl/eyDbrM Advanced Entity Framework 6 Scenarios for an MVC 5 Web Application (12 of 12) | ASP.NET MVC Site 10/29/2014 Page 22
- 23. Do we stillneed Repository and UoW ? 10/29/2014 Page 23
- 24. Consider following scenarios without repositories 10/29/2014 Page 24
- 25. In Summary •Business objects should interface with a business oriented storage service • Data objects should interface with a data oriented service • The repository should be the bridging mediator • BUT the real use case for the Repository pattern is in dealing with multiple persistence services 10/29/2014 Page 25
- 26. Sample project hostedat GitHub https://github.com/hatimhakeel/UniversityVille 10/29/2014 Page 26
- 27. Thank You Questions? 10/29/2014 Page 27