iyo is doing something like this bad practice? (us...
# announcements
a
iyo is doing something like this bad practice? (using KMongo here but it really doesn’t matter)… I just feel there should be some abstraction layer between mongo and the app, but building the abstraction layer usually is just a matter of writing brain-dead code
t
GL with this. in my experience it is a long discussion full of mantras. personally, it would boil down to one (or few) considerations: • how likely are you to change persistence layer • how hard would it be to perform such change the code without abstraction vs with abstraction • what features of the native implementation are you going to lose (if your abstraction is proper something must be left out, not all implementation would support same set of features. for instance spring-data-mongo throws a bunch of events behind the scene, but if you use them you are binding yourself to that library no matter what you abstraction/wrapper says) the problem I have with this kind of abstractions is that, like you said, they are very dumb (usually), but otoh it is still extra code, giving extra chances for a typo or whatever bug to cripple in in the end, the famous hexagonal architecture is a risk/cost analysis (which arguably can be hard to do at early stage)