How to merge multiples repositories response in the use case

[matiasdelbel]

In the examples, I see that you are returning the repository result, without implementing any other operation against them. But it is common, that in an use case you have to query a repository and then operate again it result, maybe inserting the result into other repository. How do you handle this scenario?

interface OneRepository {
   fun operation(): Either<Error, Boolean>
}

interface OtherRepository {
   fun otherOperation() : Either<Error, Int>
}

class UseCase(val repository: OneRepository, val otherRepository: OtherRepository) {

   fun run(): Either<Error, String>() {
     val result = repository.operation()
     // TODO("If the result is success, then call the second repository, and if that result is also success return a success result")
    // TODO ("How we can handle the error for both repositories?")
   }

}

[rommansabbir]

Hi, I believe that UseCase following Single Responsibility Principle means they designed to do only a single task.

So, in that case we need to combine multiple UseCase into a single.

I have already created an issue regarding this scenario.

Issue Link: https://github.com/android10/Android-CleanArchitecture-Kotlin/issues/111

[matiasdelbel]

Hi! I don't think that call multiple repositories in the same use case breaks the SRP. Usually to achieve a task you need to interact with different sources (repositories) and create new BO (factories).

Either way, both issues describe the same issue, trying to merge multiple results in one...

[rommansabbir]

@matiasdelbel yes, we are looking for the same answer. Also, you are right. Calling multiple repository from a single UseCase doesn't break the SRP because UseCase is supposed to a single task, but it can have multiple dependencies.

[mochadwi]

Been reading somewhere there's a snippet of adding multiple repositories into one usecases

[lrnrzg]

Have a try to combine response in a Repository layer and then pass the Repository to a new UseCase.

[Luistlvr1989]

SRP is not related to actually doing one thing, but to the reasons to change. Basically: "A module should be responsible to one, and only one, actor.”