@@CharfaouiYounes I would also say, that it adds inconsistencies. How would you explain to new team members when to use usecases and when not? If you would use usecases all the time it's a clear guideline and easy to understand. Another argument pro usecases would be the reusable of code. If you add access to a repo directly in the view model and maybe some little business logic it will be hidden for other view models/developers which/who might want to use exactly the same access and the same simple logic. It end up in redundant code.
I like that approach and the video and I align with it, but how would you manage that scenario when you want to call just a simple method from repository without modification (no business)? in terms of CA, the viewmodel can't have access to the repository. Would you create a "new layer" for that data or, even it breaks the rule of "Use Case" would you still use it to keep the separation of concerns? Thanks
If there is a clear separation in your case with boundaries set by your team, then you have no choice, but I wanted to clarify that even such boundy shouldn't be there if most of our call to repository are simple forwarding!
Learn something new. ❤
But isn't this will create inconsistency, like some viewmodels have repository some has useCases? 🤔🤔
It shouldn't be, you're favoring small inconsistency over huge overhead
@@CharfaouiYounes I would also say, that it adds inconsistencies. How would you explain to new team members when to use usecases and when not? If you would use usecases all the time it's a clear guideline and easy to understand. Another argument pro usecases would be the reusable of code. If you add access to a repo directly in the view model and maybe some little business logic it will be hidden for other view models/developers which/who might want to use exactly the same access and the same simple logic. It end up in redundant code.
Excellent Work. i also same thing
Une Excellente explication et simple pour apprendre ... Bon continuation frère
I like that approach and the video and I align with it, but how would you manage that scenario when you want to call just a simple method from repository without modification (no business)? in terms of CA, the viewmodel can't have access to the repository. Would you create a "new layer" for that data or, even it breaks the rule of "Use Case" would you still use it to keep the separation of concerns? Thanks
If there is a clear separation in your case with boundaries set by your team, then you have no choice, but I wanted to clarify that even such boundy shouldn't be there if most of our call to repository are simple forwarding!
What is this plugin you have? It says simple?
"Code Complexity," I think. Someone I worked with used a similar one.
Code Complexity
For audio please use some ai voice that has a better & (listenable) accent
Sure