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 ?