Hi!
Yes, it is ok to pass more different repositories to a single use case.
Thanks for the article. It might take a couple of more reads and then a practice myself. My one bit of feedback would be is that Iād have preferred it to have been done in MVP. I feel the article strayed off into MVVM territory too much in the latter half, which I know a little about, but this was quite complex MVVM, so the article stopped being about Clean and about MVVM instead.
It is a good tutorial for clean arch but i would highly recommend having the extra work to properly implement it with koin otherwise this is only partly complete.
Can i see your JSON Response to compare it with mine?
Hi,
sorry for such a late response.
Which JSON Response are you referring to? There are no network request made from the example project so Iām not sure.
Hey @ikust
Can we inject usecase inside another usecase?
Where does filtering, sorting belong in the layer?
If two usecases are almost doing the same thing but dealing with different domain models, different data source, should they be in one usecase?
I am using Firebase Firestore which supports Observable get requests. Could you suggest how to implement it in clean?
Currently, my repository implementation class has LiveData (from AndroidX) & QuerySnapshot(from Firebase) as the function return type. Which mean framework related imports would enter into domain layer.
Could you explain how this can be done properly.
Hi @sagarsuri ,
Can we inject usecase inside another usecase?
the important thing is that Use Case doesnāt depend on anything from framework or presentation layers.
So, if you have a case where injecting another use case makes sense thatās fine.
Where does filtering, sorting belong in the layer?
I think a good guideline is to place business rules and logic in the domain layer. If there is logic that is only specific to a certain Use Case and is not a part of business rules (for example sorting or filtering of data to display them a certain way in some Use Case) I think it can go in the Use Case layer.
If two usecases are almost doing the same thing but dealing with different domain models, different data source, should they be in one usecase?
I think it depends on the Use Cases. Ideally, a single Use Case should represent, a Use Case in the app.
Iāll try to explain my point of view on the example app from the tutorial:
Adding a bookmark in the example app is one Use Case.
Adding a Document to your library is another Use Case. But I wouldnāt try to fit those two use cases into one just because they both do the same operation on different domain models (add them to collection).
Hey @ikust
I see all the Usecase classes are concrete classes. As per design principles, we should program for interfaces right? What is your opinion on this?
Hi @sagarsuri,
I think itās ok to have Use Cases as concrete classes and it isnāt against SOLID principles. At the moment I canāt think of a situation where you would profit from having separate interfaces and implementations of Use Cases.
Iāve read so many articles and watched so many videos about knowing what is clean architecture and how to implement clean architecture and layers usage. But i couldnāt get the concept. After reading your articles iāve understood whole concept and i decided to give you a comment. Thanks for your greatly explained articleā¦
2 Likes
This tutorial is more than six months old so questions are no longer supported at the moment for it. Thank you!