Repository Pattern RRS feed

  • Question

  • public interface IRepositoryBase<T> 
            object Create(T obj);
            T Retrieve(Guid key);
            int Update(T obj);
            int Delete(object key);

    I often saw this kind of interface every time  i'm reading about Repository pattern. Some might be slightly different but the intent is to make sure all the inheriting class will implement all these methods. Aside from that, i don't see any much benefit following this approach. I can easily create those methods myself without needing the inheritance as some table might not need one of those methods resulting in throwing not implemented exception(You can use interface segregation here though). I guess interface inheritance is not only making sure the inheriting class implement those methods but to solve problems like polymorphism. That's what i'm interested to look into but haven't find any example yet on using this pattern.

    I would love to see a simple code snippet showing how can i achieve polymorphism here.


    • Edited by Dikong42 Thursday, November 2, 2017 4:41 AM
    Thursday, November 2, 2017 4:39 AM

All replies

  • You're under the mistaken impression that a Repository pattern's sole purpose is to be generic and for database persistence.  

    I have never used the repository object in the above manner, because the repository object may need to do more than generic DB activities, like call other repository objects, services or even the repository object itself may need to do more specialized DB activities that are not generic, which can be dependent upon business needs.


    Use a repository to separate the logic that retrieves the data and maps it to the entity model from the business logic that acts on the model. The business logic should be agnostic to the type of data that comprises the data source layer. For example, the data source layer can be a database, a SharePoint list, or a Web service.


    If the repository pattern is being used, then you might want to consider that the repository object calls a DAL with the DAL using Data Access Object pattern for low level CRUD operations with the DB.

    You should use the DTO pattern with all projects in the solution having reference to the project that contains the DTO(s) so that all projects know what the DTO(s) are about.


    Thursday, November 2, 2017 12:15 PM
  • A Repository in C# mediates between the domain and data mapping layers (like Entity Framework). It allows you to pull a record or number of records out of datasets, and then have those records to work on acting like an in-memory domain object collection, and you can also update or delete records within those data set, and the mapping code encapsulated by the Repository will carry out the appropriate operations behind the scenes.

    Why Repository Pattern C# ?
    Increase testability: Repository systems are good for testing. One reason being that you can use Dependency Injection. Basically, you create an interface for your repository, and you reference the interface for it when you are making the object. Then you can later make a fake object (using moq for instance) which implements that interface. Using something like StructureMap you can then bind the proper type to that interface. Boom you’ve just taken a dependence out of the equation and replaced it with something testable.

    Easily swapped out with various data stores without changing the API: For example, in one instance, you may need to retrieve data from the database, in other cases you may need to retrieve something from a third-party API, or perhaps there’s some other place from which you need to retrieve data. Regardless, the idea behind the repository pattern is that whatever sits behind it doesn’t matter so long as the API it provides works for the layer of the application calling into it.

    You will not see much benefit following this approach as Entity Framework (EF) itself implements Unit of work pattern and somewhat loosely implements Repository pattern. With EF you can retrieve a set of records from the database in POCO models. Also, EF keeps track of changes for you within these models and save these changes on single SaveChanges method call. 

    Thus, many people argue on using repository pattern over EF. For more information, see

    Wednesday, February 12, 2020 6:08 PM