Repository Pattern Step by Step Explanation [closed]

Question

Can someone please explain to me the Repository Pattern in .NET, step by step giving a very simple example or demo.

I know this is a very common question but so far I haven't found a satisfactory answer.

Radburn

msdn.microsoft.com/en-us/library/ff649690.aspx and codeproject.com/Tips/309753/… – Ruthannruthanne

There's a good write-up here: deviq.com/repository-pattern – Cockneyism

martinfowler.com/eaaCatalog/repository.html "Mediates between the domain and data mapping layers using a collection-like interface for accessing domain objects." – Chewy

Answer 1

As a summary, I would describe the wider impact of the repository pattern. It allows all of your code to use objects without having to know how the objects are persisted. All of the knowledge of persistence, including mapping from tables to objects, is safely contained in the repository.

Very often, you will find SQL queries scattered in the codebase and when you come to add a column to a table you have to search code files to try and find usages of a table. The impact of the change is far-reaching.

With the repository pattern, you would only need to change one object and one repository. The impact is very small.

Perhaps it would help to think about why you would use the repository pattern. Here are some reasons:

• You have a single place to make changes to your data access

• You have a single place responsible for a set of tables (usually)

• It is easy to replace a repository with a fake implementation for testing - so you don't need to have a database available to your unit tests

There are other benefits too, for example, if you were using MySQL and wanted to switch to SQL Server - but I have never actually seen this in practice!

Winther

RE switching from dbms a to b, I'll go on record that not only have I seen this, I've done this in production code. We were previously using Oracle, had to switch hosting provider, settled on Azure (before they supported Oracle), so we had to convert to SQL Azure. Unfortunately, we had not separated all data access logic at that point, but we certainly did it as we did that migration (and going forward, I might add). – Sterilize

I know this comment is old and closed as off-topic, but I've seen this done in multiple companies. Typically, it's part of a process to move towards or away from an ORM. The repository makes it easier to switch it out, especially if you load them from an abstract factory pattern or using an IoC container. – Rime

Actually Repository uses DAO for it's data source related operations... – Stromboli

@YoushaAleayoub that a good point you raise. You'll typically find Data Access Objects when people are trying to "separate the database" and repositories when people are trying to "make a single thing responsible for the query". In almost all cases, you'll find both together. The DAO part is the IConnection, ICommand, etc part that hides the type of database. The repository is usually more domain-centric. – Winther

Answer 2

This is a nice example: The Repository Pattern Example in C#

Basically, repository hides the details of how exactly the data is being fetched/persisted from/to the database. Under the covers:

• for reading, it creates the query satisfying the supplied criteria and returns the result set
• for writing, it issues the commands necessary to make the underlying persistence engine (e.g. an SQL database) save the data

Selfimprovement

This example is best explanation ever, simply better than MSDN documentation. – Mendymene

I found this very good. It also provides decent explanation on Unit of Work, which seems to be more generic form of the Data Pattern over the Repository Pattern – Apiarist

The linked example is a repository pattern failure. It gives no advantage at all compared to using the interfaces provided by Entity Framework (IDbContext) or in nhibernate (ISession) directly. A correctly implemented repository abstracts away ALL persistance specific information (like how the current Linq To Sql provider works). i.e. never expose IQueryable. – Valvule

@Valvule IQueryable isn't persistence specific information. The backing of the IQueryable could be as simple as a hard coded array, or it could be from a XML file, web service, database, flat file, etc. I wouldn't recommend a repository that didn't expose IQueryable as it always leads to slow data access in every case, where exposing IQueryable will allow some instances to do performance enhancements where applicable if the persistence store has that capability. Additionally, hiding away DbContext allows you to switch to a different ORM if need be (or no ORM!) – Eldridge

It leaks persistence information specific information. Try to use eager/lazy loading or building an IN sql clause without knowing how the specific LinqToSql provider does it. – Valvule

Thanks for sharing this link,its really useful codeproject.com/Articles/615499/… – Spiegel

In his IRepository<T> we can see IQueryable<T> and won't that be an additional work around ? or is it better to have IEnumerable<T> instead ? – Cheerless

" repository hides the details of how exactly the data is being fetched/persisted from/to the database" it's DAO's duty... – Stromboli

TBH, Repository pattern can only be used in trivial applications. My app is interacting with hundreds of tables across several databases and how on earth would it be maintainable to create a separate repository for each and every table entity?! Perhaps if you have like 5 tables then this can be pulled off and maintained, but otherwise it is useless. – Chapell