Is repositories depending on repositories a bad id...
# android-architecture
u
Is repositories depending on repositories a bad idea down the line?
s
I would assume so, preferrably the repository should be specific and interactions between two repositories should be done in a UseCase
☝️ 2
t
In DDD yes, but most repositories probably don't adhere to DDD and are more like DAOs. But DAOs that depend on each other are also questionable.
o
I don't think there's something wrong with a repository holding and using another repo, if it makes sense. I guess naming convention here is calling it Use case but it's no different from any other repo. E.g. all logging to your API is done through repo #1. Repo #2 encapsulates fetching data from an API and updating your local db, and if your DB or fetching/processing of some data requires you sending some log to your backend, then repo #2 holds a reference to repo#1 and calls the appropriate function on it. I think the issue becomes when there is a circular dependency between these two repos. And in that case you would need a third repo/use case class which holds a reference to both of these repos and calls the appropriate methods on each.
s
ideally you would have one repo responsible for handling crud for a particular entity e.g User. Which would include api calls as well. having separate repositories handling same entity but different sources won't really make sense. Making your repositories be devoid of other repository dependencies also helps to avoid cyclic dependencies and the need of introducing proxy classes
a
Would need to know the use case but I have done this at least once for caching.
s
cool
u
Well exact use case is, my various features are locked behind Permissions, so if I dont have a permission x, then shouldnot be able to see data Y, so what I do, is I have FooRepository which exposes observable of List of Foo. That repo depends on PermissionsRepository which exposes permissions stream. FooRepo then uses this stream to switchMap the list of Foo with empty if permission is not there
so when permission goes away, FooRepo emits a empty list of Foo to its subscribers
tldr; PermissionRepo is a dependency of FooRepo . is that cool? I kind of worry about cyclical refs down the line
s
in this case yes down the line you would get cyclical dependency. What I would advise is remove permissions as a dependency to FooRepo. Then create a UseCase that would take in Permission Repo and FooRepo as dependencies then have the logic of if permission granted execute method A from FooRepo and if no permission execute method B from FooRepo. this way the UseCase is specific to this scenario and your repositories function as they should which are data access points.
u
hm, but that implies everybody has to use that GetFooFilteredByPermssionsUseCase right?
and have to pay attention not to use FooRepo directly
s
yes exactly
a
I agree for this case a repository shouldn't do anything related to permissions. Its more of a data mapping / abstraction layer. My exception for this was caching which has a little bit of business rules (how long to cache for example) but ultimately its just abstracting where the data is coming from.
s
Exactly abstraction is the main idea, and as well being able to adequately manage dependencies