Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Why not using separate datasource(Local-DB, Cloud-API) in the reposiotry? #8

Open
souravpalitrana opened this issue Mar 8, 2018 · 8 comments

Comments

@souravpalitrana
Copy link

souravpalitrana commented Mar 8, 2018

Here repository is the bridge to get data from Database. It has no other data source. So if you want to use data cache what will you do? In that case, it will be better if repository may have two data sources. One is local data store and another is cloud data store or you can use a data store factory to create a data source for the repository. I am telling that because it is a standard boilerplate. If you add that then it will help others in that scenario.

I want to know your opinion.

@janishar
Copy link
Owner

janishar commented Mar 8, 2018

The Interactor is designed to be use specific.

If an Interator need data from disc/ memory cache then we can create a DiscCacheHelper/MemCacheHelper and provide this helper to that Interactor just like Repositories.

Repositories only deals with methods for the data in the database.

For cloud data we have ApiHelper.

You are right we could possibly segregate Repository into LocalRepository and RemoteRepository but since for RemoteRepository we have used ApiHelper so we assume that a Repository to be LocalRepository.

If we have a very large number of API endpoints and we think to modularize ApiHelper then we can replace ApiHelper with RemoteRepository. But that may be an overkill for most of the apps.

@souravpalitrana
Copy link
Author

souravpalitrana commented Mar 8, 2018

@janishar So in that case, you have to introduce DiscCacheHelper and your interactor need to decide from where it will pull the data. But I am suggesting that as you are already using repository then your repo can handle that.

A repository will ensure us that the interactor will get the data. Interactor should not know about data abstraction (Local, Cloud, Test). Again in that case interactor will be less complex as it doesn't need to handle all the helper class.

Again if you want to use another helper you have to add that in all interactor.

@IomarSantos
Copy link

What would be the strategy for saving local or remote data using LocalRepository RemoteRepository would have to inject the two into Interactor?

@souravpalitrana
Copy link
Author

@IomarSantos You should not inject localRepository and remoteRepository both. You should inject a repository. A repository should handle from where it will provide data. However, the repository can use a DataStoreFactory which will provide local or cloud data source based on logic.

@Drjacky
Copy link

Drjacky commented Jun 6, 2018

@souravpalitrana I agree totally with you on Repository design pattern subject, that I think not correctly observed in this example.

And by the way, It would be nice if you could fork this example and implement that 🙏

@janishar
Copy link
Owner

janishar commented Jun 6, 2018

@souravpalitrana I think there is a confusion. This repository is not analogous to the Repository pattern as the abstraction layer for the data from any source as the android architectural components describe. In this example, the repository is the concept used in database abstraction like in hibernate. Refer to this: https://thinkinginobjects.com/2012/08/26/dont-use-dao-use-repository/

@Drjacky
Copy link

Drjacky commented Jun 16, 2018

@janishar In related to your last comment, so maybe it's better to change the name of Repository to something else; To prevent its similarity to Repository Pattern. 🙏

@janishar
Copy link
Owner

janishar commented Jun 18, 2018

@Drjacky Okay! I will try to find a less confusing name.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants