Repository and Unit Of Work Design Patterns tech talk delivered on 10/29/2014 at The Cave, Embla Software Innovation.

1. Repository and
Unit of Work
Design Patterns
29th October 2014
Presented By: Hatim Hakeel

2. 10/29/2014 Page 2

3. Repository
Object-Relational Metadata Mapping
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 Behavior Patterns
• 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 5 and 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 Bigger Picture
10/29/2014 Page 9

10. A possible project structure
10/29/2014 Page 10

11. IUnitOfWork interface
10/29/2014 Page 11

12. UnitofWork.cs i
10/29/2014 Page 12

13. GenericRepository<TEntity> Getters ii
10/29/2014 Page 13

14. Persist DbContext changes and clean
up resources iii
10/29/2014 Page 14

15. IGenericRepository<TEntity>
10/29/2014 Page 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 the architectural wiring come
live in the controller ?
10/29/2014 Page 20

21. Sample Edit, Get(…) calls
10/29/2014 Page 21

22. Entity Framework 6 and 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 still need 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 hosted at GitHub
https://github.com/hatimhakeel/UniversityVille
10/29/2014 Page 26

27. Thank You
Questions ?
10/29/2014 Page 27