The repository pattern allows you to hide data source specific implementation from your core application.
For example, if you wanted to get a list of users for your application using the repository pattern, you might call into a class called UserRepository to return a list of users. The application doesn’t need to know where the class retrieved those users from; it just needs a list of users. Behind the covers of UserRepository you can have multiple provider classes. One for each data source.
Let’s assume you started off by just using Active Directory for the users of your application. Later down the road, needs changed and now you need to move to a SQL backend data source. If you followed the repository pattern, it’d be relatively easy to switch out your data source without interrupting the application layer. First, you’d need to implement a new provider class for the repository to use that interacts with the database for all your user based needs instead of AD. Next you would tie the new SQL provider class in with the existing user repository class. Following this approach allows you to retain the same interface with your application so the application logic doesn’t need to change.
The diagram below visualizes this concept.