Repository and Unit Of Work Design Patterns
-
Upload
hatim-hakeel -
Category
Software
-
view
266 -
download
2
description
Transcript of Repository and Unit Of Work Design Patterns
Repository and
Unit of Work
Design Patterns
29th October 2014 Presented By: Hatim Hakeel
10/29/2014 Page 2
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
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
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
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
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
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
The Overall Bigger Picture
10/29/2014 Page 9
A possible project structure
10/29/2014 Page 10
IUnitOfWork interface
10/29/2014 Page 11
UnitofWork.cs i
10/29/2014 Page 12
GenericRepository<TEntity> Getters ii
10/29/2014 Page 13
Persist DbContext changes and clean
up resources iii
10/29/2014 Page 14
IGenericRepository<TEntity>
10/29/2014 Page 15
GenericRepository<TEntity>
constructor i
10/29/2014 Page 16
IEnumerable<TEnitity> Get(…) ii
10/29/2014 Page 17
Remaining CRUD method
implementations iii
10/29/2014 Page 18
EF DbContext implementer
10/29/2014 Page 19
How does the architectural wiring come
live in the controller ?
10/29/2014 Page 20
Sample Edit, Get(…) calls
10/29/2014 Page 21
Entity Framework 6 and ASP.NET
MVC 5
10/29/2014 Page 22
From http://goo.gl/eyDbrM Advanced Entity Framework 6 Scenarios for an MVC 5 Web Application (12 of 12) | ASP.NET MVC Site
Do we still need Repository and
UoW ?
10/29/2014 Page 23
Consider following scenarios
without repositories
10/29/2014 Page 24
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
Sample project hosted at GitHub https://github.com/hatimhakeel/UniversityVille
10/29/2014 Page 26
10/29/2014 Page 27
Thank You
Questions ?