Implementing The Repository And UnitOfWork Pattern In C# And Entity Framework

The Repository and Unit Of Work Pattern are two very useful Design Pattern used when working with data. The Repository pattern is used with logical collections of objects and it acts as an in-memory collection for business entities, abstracting away the underlying data infrastructure. That is, when you use the repository pattern, you don’t have to design your Data Access logic/layer based on the the specifics of what kind of data store or what kind of technologies will be used to query it.

The Unit Of Work pattern, on the other  hand, is designed to maintain a list of business objects that have been changed by a business transaction, be it adding, updating or deleting, then it coordinates the changes as one atomic action. If there are problems the entire transaction rolls back.

There are lots of blog posts and articles, that shows  examples on how to implement this in C# & Entity Framework, and you will find out that different people with different ways in which they’ve used this pattern, and in this post I won’t be doing any code demonstration  instead, I’m sharing a link to my code implementation on GitHub and links to other sources where you can read more about it.

My code on GitHub

Design Patterns by the Gang Of Four

Professional ASP.NET Design Patterns by Scott Millet

I use the code in GitHub to kickstart my repository implementation by creating Repositories related to the specific need of my application which inherits from the BaseRepository class (which is a Generic class that implements my basic CRUD operations) and then implement specific operation in those repository classes e.g GetFollowersByID(id), GetCommentByTopicId(topicId), just anything related to that repository and as time goes by, if I find a better way to perform this kind of task, my code on GitHub will change.


2 thoughts on “Implementing The Repository And UnitOfWork Pattern In C# And Entity Framework

  1. Why would you use repository pattern and UOW-pattern over EF, when EF already implements these patterns internally?

    In my opinion it’s just makes it harder to work with the DB.

    From the documentation:
    “A DbContext instance represents a combination of the Unit Of Work and Repository patterns such that it can be used to query from a database and group together changes that will then be written back to the store as a unit. DbContext is conceptually similar to ObjectContext.”

    1. It’s true EF already implements these patterns internally. NHibernate also encapsulate these patterns internally. The repository and unit of work patterns are intended to create an abstraction layer between the data access layer and the business logic layer of an application, and implementing these patterns can help insulate your application from changes in the data store and can facilitate automated unit testing or test-driven development.

      This abstraction layer contains data manipulation methods which communicates with the data access layer to serve data as per the business requirements. You can also add application specific logging, or error handling to transaction management. It also makes it easier to swap out EF for any other persistence tool.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s