Stiamo lavorando su API che chiamano altre API che recupereranno / aggiorneranno inevitabilmente un sistema di record come SQL, MySQL o altri database. A volte avremo 3/4 livelli di API prima che venga colpito il SOR.
Normalmente userei una classe repository quando eseguo funzioni su un sistema di record direttamente tramite Entity Framework o ADO.NET ecc.
In questo caso, non interagiamo direttamente con un SOR, ma tramite un'altra API.
Questa logica dovrebbe essere presente nel servizio piuttosto che nel repository?
Piuttosto, c'è un vantaggio reale nel separare questo codice in una classe di repository?
Per quanto ne so, una classe di repository non dovrebbe contenere alcuna logica di business.
Lo scopo o il vantaggio principale di un repository per me è la capacità di disaccoppiare il DAL dal resto del codice, ad es. quando si cambia tra ad es. un database SQL e MySQL.