I'd say that if the exception is recoverable it's not really an exception but a valid case so it should be modelled as such.
Fair enough. Will definitely check your post.
but the repository pattern is useful because it abstracts from the data source that's going to be used
I agree, I guess the main difference is just - do you put all functions in a Repository class, or do you have a bunch of separate functions - perhaps living closer to the usecases that they are used in, perhaps even as private functions to the usecase (function or file), i'm leaning more to the latter, as growing a repository class with single use functions seems to me just not that useful. It centralises them, but as they're often single-use, their ideal place seems to be more close to their use.
That's a nice one. If we simplify things to the extreme, you can strip classes and interfaces and have only functions left.
Yep, 100 with you, I prefer doing this with functions. When the language allows, doing this with just functions is awesome.
Except on the pure part; i'm fine with the Interactors depending on impure functions (only known by interface, not implementation), imo that's their main purpose;
receiving input from delivery mechanism - calling impure, pure, impure - producing output for the delivery mechanism.
Of course Jimmy has a word on that too ;-) lostechies.com/jimmybogard/2012/10...
(it stands at the basis for the Query/Command handlers, which is an evolution of this)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Fair enough. Will definitely check your post.
I agree, I guess the main difference is just - do you put all functions in a Repository class, or do you have a bunch of separate functions - perhaps living closer to the usecases that they are used in, perhaps even as private functions to the usecase (function or file), i'm leaning more to the latter, as growing a repository class with single use functions seems to me just not that useful. It centralises them, but as they're often single-use, their ideal place seems to be more close to their use.
Yep, 100 with you, I prefer doing this with functions. When the language allows, doing this with just functions is awesome.
Except on the pure part; i'm fine with the Interactors depending on impure functions (only known by interface, not implementation), imo that's their main purpose;
receiving input from delivery mechanism - calling impure, pure, impure - producing output for the delivery mechanism.
Small follow-up on Repository, so i'm kind of more in the boat of:
and then using these functions in the interactor, instead of encapsulating specific queries in single use methods in the Repository.
Of course Jimmy has a word on that too ;-)
lostechies.com/jimmybogard/2012/10...
(it stands at the basis for the Query/Command handlers, which is an evolution of this)