4

I'm currently working on the project with the new team and they are using Repository pattern which is new to me. In this repository, they're currently doing 

1.If we are offline, we will load data from file
2.Otherwise, we will make an api call to get data from server.

I did some researches and noticed that Repository is providing basic CRUD operations to local database. However, if we consider Repository acts like Data Access Layer, it can make an api call to retrieve data remotely as well.

Which one is the correct way to follow. Any ideas ?

Improve this question
  • First, the correct order is: Make the API call to get data from the server; if it fails load data from the file. Plus check if it is a problem that the user can fix and ask them to fix it (but carefully to avoid getting on their nerves). You cannot reliably determine that you are offline. – gnasher729 Nov 29 '16 at 17:11
  • You can also use data from local storage immediately, make the API call simultaneously, and update things if the call succeeds. – gnasher729 Nov 29 '16 at 17:11
9

The purpose of a Repository is to provide an abstraction layer for data access. That abstraction layer should shield the user of the repository from the details of accessing the data. Things like connection strings, data sources, switching to a different data source... Your user shouldn't have to worry about those things.

In other words, the user of a Repository should not have to be concerned about where the data is coming from. That is an implementation detail. How you implement that detail is entirely up to you and your software's specific requirements.

Improve this answer
2

An implementation of the Repository pattern should appear to be an in-memory collection of objects. You should be able to add, remove and find objects in a Repository. It should not have any database-like semantics such as Save() or CommitTransaction - these belong on your Unit of Work implementation. This is sometimes referred to as "Persistence Ignorance."

Generally, application code will work against the Repository, and your application infrastructure will automatically flush changes and commit the transaction via the Unit of Work after handling each request. Each request will get one instance of the Unit of Work, which will be shared by all the Repositories used to handle the request. This is sometimes referred to as "Session per Request."

Improve this answer
0

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. Implementing these patterns can help insulate your application from changes in the data store and can facilitate automated unit testing or test-driven development (TDD).

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.