https://kotlinlang.org logo
v

Vikas Singh

09/16/2022, 2:59 PM
Is it good to have a use case depending on another use case where the other use case is just forwarding the calls to the repository ?
m

Marko Novakovic

09/16/2022, 3:36 PM
if it’s the pattern to have usecases that are just delegating calls to repository and you already have usecase that does what you need than it’s ok to depend on it
it’s ok for a usecase to depend on another usecase
k

K Merle

09/16/2022, 7:12 PM
I agree with @Marko Novakovic. It's just a high lvl code and doesn't break unidirectinal flow
v

Vikas Singh

09/17/2022, 5:58 AM
What if in future I add a business logic to the usecase which is now just forwarding the calls to repo..
k

K Merle

09/17/2022, 7:17 AM
It depends what kind of logic and in what situation.
m

Marko Novakovic

09/18/2022, 8:27 AM
just don’t duplicate code. if you end up adding code to some usecase that you depend on and it’s not suitable any more for some other usecase, create new usecase or call repository directly
don’t overcomplicate 🙂
v

Vikas Singh

09/19/2022, 11:56 AM
I was thinking of not having a usecase just to forward the calls to repo instead directly call the repository The current usecase class UseCaseA(val usecaseB: UseCaseB) { fun execute() { useCaseB.saveData() } } In the above example usecaseB is just forwarding the calls to repo instead i would prefer to directly inject the repository
z

zhuinden

09/29/2022, 5:25 PM
as always, i'd just remove the repositories and move all that code into usecases that don't depend on each other
m

Marko Novakovic

09/29/2022, 10:51 PM
interesting, why not? if, for example, you already have some non trivial behaviour covered with a usecase, why not use that usecase if you need that exact behaviour?
a

ajay meher

09/30/2022, 11:18 AM
A UseCase can be a meta UseCase and have part of it’s responsibility/task be executed/delivered by other UseCases and work on the result to achieve the final responsibility. But, if it is only about a UseCase delivering some other UseCase result directly then my suggestion would be to use the original UseCase directly. Every UseCase should follow SRP and should have only one reason for change. In your case, you are still going to violate DRY if you copy the same responsibility from existing UseCase.
p

Pablichjenkov

10/07/2022, 5:41 AM
I would make the use case being a custom kotlin flow operator and concatenate them if one depends on the other output. That way you gain a free coroutine scope already in the flow {} builder
t

Thanos Psaridis

10/25/2022, 3:29 PM
We do that all the time in my company. Our project is heavily modularized and focused on clean architecture.
520 Views