Il mio repository o servizio dovrebbe essere responsabile per l'unione di più chiamate API in un unico oggetto

Question

Il mio repository o servizio dovrebbe essere responsabile per l'unione di più chiamate API in un unico oggetto

#1 da (1 voti)
#2 da (0 voti)

1

Sto implementando il pattern di repository nella mia applicazione.

Il repository si connetterà a un'API per scaricare gli ordini da un'API esterna. L'API a cui mi sto connettendo ha un endpoint separato per ottenere l'elenco di ordini e un endpoint separato per ottenere gli articoli rispetto a tale ordine.

Dove dovrebbe accadere il matrimonio di OrderItems e Orders ? Se la funzione GetOrders() nel mio repository ottiene ordini e articoli, restituiscili al servizio con entrambi gli ordini e gli articoli. O il livello di servizio dovrebbe essere responsabile dell'esecuzione di GetOrders() e GetOrderItems() e di unirli insieme?

Spero che abbia un senso!

api repository

posta Lock 03.05.2017 - 12:40

fonte

2 risposte

Leggi altre domande sui tag api repository

Cercando di insegnare a uno studente delle scuole superiori Dynamic Memory Allocation - quali sono i modi migliori per farlo? Come posso applicare CI / CD a un processo di sviluppo "flessibile"

score 1 · Answer 1

Un principio del design basato sul dominio potrebbe essere utile qui. Radici aggregate.

Se l'oggetto Order contiene oggetti, ad esempio Order.Items, quando si ottiene un ordine dal repository di ordini, è necessario che tutti gli elementi siano compilati.

Se non contiene un elenco di elementi, puoi avere un ItemsRepository separato con un metodo GetItemsForOrderId (id stringa)

L'idea è che tu possa avere una regola sull'oggetto Ordine che dipende dagli Articoli. dì che puoi avere un ordine con più di 10 articoli. Avere il metodo OrderReposity.SaveOrder () con gli articoli Orders consente di applicare questa regola prima di mantenere l'ordine.

La mia regola generale è di avere un repository per database. Poiché all'interno di un database è probabile che le tabelle vengano unite in vari modi e quindi abbiano queste regole interconnesse.

score 0 · Answer 2

Generalmente nella progettazione N-Tier avresti un livello di classi "client" di basso livello che si occupano di parlare alle API di back-end. E un livello di classi 'delegate' (business logic) che si occupano di integrazione. Il tuo livello Controller / Vista può quindi chiedere l'appropriato "delegato" per un elenco aggregato. Se il tuo layer è semplicemente un traduttore di protocolli, il proxy delle API non ha un livello di logica aziendale. Ma perché il tuo cliente non può semplicemente chiamare direttamente l'API? Qual è il punto del tuo livello? Mi sembra che dovresti eseguire la logica di business.