•

•

•

•

•

•

• • Whitepaper July 2013

INTRODUCTION

Entity Framework

Linq to SQL

SharePoint Lists data access

Web Service Data access

REST Services

Custom Data Access

REPOSITORY PATTERN: CASE STUDY

Figure 1: Repository pattern as intermediate between front end and Data access

This case study discusses about a QuickBooks based analytical solution. The main requirement of this project wasto get the data from QuickBooks and build analytical solution on top of it. The front end stack involved ASP.NET based portal, Outlook add-in and mobile App. On a highlevel, the architecture involved writing a scheduler to poll data from QuickBooks and store in a MS-SQL database (QuickBooks database). For legacy reasons another database instance was maintained whichhad user and portal information (Application database).

Analytical components on the front end require interacting with QuickBooks database as well as Application database. The mobile component requires a REST service for interacting with the two databases.

The solution design needs a data access and business layer which can interact with these two databases. Developers should be able to build this layer such that it is unit testable. It should also be extensible from futuristic requirements point of view.

Business Problem

Solution

The solution revolved around designing two major parts i.e. DataAccess Repository and Business Repository. Data Access Repository is responsible forproviding layer for accessing QuickBooks data. Business Repository is responsible for providing layer for accessing application data such as user information.

Agile Design Patterns: The Repository Pattern Ver. 1.0

based on entities within the business domain. Typical business Software application would have a front end (desktop or web) and a Back end (RDBMS). 95% of domain driven design based application involves transaction from front end or external source to database.There are some commonly used design patterns around transactions and this document covers one such design Pattern – The Repository Pattern. Repository pattern on a high level is defined as an interface which helps in abstracting out a layer between data access layer (in case of classic 3-tier architecture) / ORM layer (such as NHibernate/Entity framework) and business logic layer or Domain. This interface generally has method parameters as Domain objects or Generic objects.The implementation of the interface has code using data objects in accordance to the implemented data source layer. The responsibility of Repository Pattern is to provide ability to query and fetch results from a data store without the knowledge of underlying data store. Repository pattern has very generic nature and hence can be implemented on top of following data access / ORM layer:

I

These layers perform the desired data actions on the database while a repository performs the business operations on the data to be sent to the data store or received data.

n today’s world one of the most prominently used architectural styles is Domain Driven Design. Domain Driven Design involves an object orientedarchitectural style focused on modeling a businessdomain and defining business objects

Figure 2: High level Data access repository design

1. Application has used entity framework to setup data models in database first approach. 2. Since two different databases exist; two different models have been prepared. 3. To make sure behavior of these two databases is same; the default code generation module was modified to inherit common classes.

Figure 3 Generic Repository class

Figure 4 DBContext Factory Class

Figure 5 Database Model Base Classes

Agile Design Patterns: The Repository Pattern Ver. 1.0

DATA ACCESS REPOSITORY

4. To perform the database CRUD operations, a generic/base Repository pattern with basicCRUD operations implemented.

5. DbRepository implements IDbRepository, which internally identifies the type of entity that gets injected with DbContextFactory.

6. DbContextFactory return the DbContext instance of the specific entity for the respective database. Type of Entity provided decides which DbContext to be used in the Data Access Repository.

7. Entity is the base database model for all the database entities.

8. Generic parameter to the DbRepository has a database model class which inherits ‘Entity’ class and hence either DBAEntity or DBBEntity.

9. Database context factory is used to get the respective DbContext object for two databases.

CRUD Repository class extracts the type of data model and request to DB context factory to get the specific DbContext instance.

10. This implementation helped us to have a common CRUD repository for any type of data stored.

With a very common approach to perform the database operations we can have logically separated business repository for each and every database model from two different databases. Database repository can be injected into business repository by implementing inversion of control or by dependency injection, which is the next level implementation of Repository pattern.

The high level solution approach for the business repository is as illustrated below:

Below steps discuss the Business Repository design:

BUSINESS REPOSITORY

Agile Design Patterns: The Repository Pattern Ver. 1.0

Figure 7 Business Repository classes

1. A common interface with all the common business operation tightly mapped to CRUD repository was implemented. This is business repository interface which has all the methods matching with the database operations.

2. Business Repository for each entity was created. Below is a sample implementation for user and Bank Transaction model.

An independent interface for User was implemented which inherits the common repository interface IRepository. The User repository implementation consisted of User model specific methods as well as generic repository methods.

Finally when user injects IUser Repository all the methods from common repository and its own will beavailable on the caller side.

Agile Design Patterns: The Repository Pattern Ver. 1.0

Dependency Injection and Inversion of Control

Ninject

Conclusion

2. Code re-usability

In the above example IoC was achieved thru Unity framework. However it should be noted that the below listed IoC frameworks are compatible with repository pattern implementation as well:

Unity

Castle.Windsor

Autofac

Structure Map

Spring.NET

•

•

•

•

•

• •

•

•

•

•

1. Highly extensible model: able to extend business logic layer to support any type of data source

4. We can leverage Repository implementation along with Unit of Work concept as temporary in-memory domain object collection. This means adding/editing/deleting objects can be done against an in-memory collection which later on can be synchronized with actual underlying data source.

3. Business layer or Domain is possible to be unit testable. If using any unit test framework we can create fake objects against the Repository interface and use Domain objects. Note: Repository patterns are truly unit testable if it has a DataMapper implementation such as DBContext in case of Entity framework.

About Nitor

Nitor Infotech specializes in Portals & Collaboration and Business Intelligence domains and provides technology and business solutions to its global customers.

Portals & Collaboration Solutions

Business Intelligence

Enterprise Mobility

Cloud Solutions

Technology Services

Healthcare Manufacturing

IT/ITeS Pharmaceutical

BFSI

Retail

Legal

© 2013 Nitor Infotech. All rights reserved. 

Our Services Industry Expertise

Information furnished is believed to be accurate and reliable. However, Nitor Infotech assumes no  responsibility for the consequences of use of such information or for any infringement of patents or  other rights of third parties that may result from its use.

Please refer http://www.codeproject.com/Articles/526874/Repositorypluspat tern-2cplusdoneplusright for an example with NHibernate.

Global Delivery Centre:

401-408, A-Wing, Pride Silicon Plaza, Near Chaturshringi,S.B. Road, Shivajinagar,Pune -411016 Maharashtra, INDIA Email: info@nitorinfotech.com Tel: +91-20-41020202