Unione di una tabella con tabella da database / API esterni

Question

Unione di una tabella con tabella da database / API esterni

#1 da (2 voti)

4

Per un progetto prototipo ho creato un'applicazione Angular 2 con funzionalità CRUD semplice che utilizza Auth0 per gestire l'autenticazione con un back-end contenente un progetto Web API (core), servizio e repository.

Ho scelto di utilizzare un database Auth0 per archiviare tutte le informazioni dell'utente (e non una tabella interna personalizzata) perché non ho visto un motivo per non farlo e voglio evitare una complessità non necessaria.

A questo punto ho bisogno di mostrare tutti gli utenti in una tabella HTML combinata con le informazioni dal mio database personalizzato, ad esempio: alcuni utenti sono collegati a un progetto, tutti gli utenti dovrebbero essere mostrati, ma solo il link-to-project gli utenti dovrebbero avere un pulsante accanto al nome. Per questo uso l'API di gestione Auth0 per recuperare tutti gli utenti. Dove sarebbe il posto migliore per unire l'utente e le tabelle del progetto che esistono entrambi in diversi database (gli utenti sono raggiungibili solo usando l'API di gestione Auth0 esterna.

Repository: recupera tutti gli utenti dall'API di gestione e tutti i progetti che utilizzano SQL, quindi combina gli elenchi.
API Web: recupera tutti gli utenti dall'API di gestione e da tutti i progetti da ProjectService, quindi combina gli elenchi.
Clientside: recupera tutti gli utenti dall'API di gestione utilizzando Angular 2 e tutti i progetti da ProjectController (API interna), quindi combina gli elenchi utilizzando javascript.
Giungiamo alla conclusione che dovrei unire il database Auth0 a quello personalizzato.

Nota aggiuntiva: se ad esempio utilizzare il repository per unire le tabelle sarebbe la soluzione migliore, che cosa dovrebbe accadere quando gli utenti dovrebbero essere mostrati su una pagina diversa senza la necessità di ulteriori informazioni. Suppongo che ora sia meglio chiamare direttamente l'API di gestione dal client, risultando in una situazione in cui le chiamate all'API di gestione vengono diffuse attraverso l'intera applicazione.

domain-driven-design repository asp.net-mvc-web-api angular2

posta Sam 05.12.2016 - 11:20

fonte

1 risposta

Leggi altre domande sui tag domain-driven-design repository asp.net-mvc-web-api angular2

Metodo suggerito per "semplificare" EAV Doppia architettura di rete neurale per attività di programmazione di IA a stella

score 2 · Accepted Answer

I escluderebbe l'opzione 3. principalmente perché sembra più semplice mantenere il concetto di una singola API per l'applicazione client; il fatto che l'endpoint dell'API Web per gli utenti chiama ulteriormente nell'API di gestione Auth0 è un dettaglio di implementazione.

Nascondere questo aspetto dalle applicazioni client rende anche più facile cambiare in futuro, anche se, non sono un grande fan della programmazione di ciò che potrebbe accadere in futuro. Tuttavia in questa occasione nascondere l'API di gestione Auth0 dall'applicazione client sembra avere più senso anche se è improbabile che quella parte del sistema cambi.

Vorrei che resista anche all'opzione 4. (anche se Auth0 supporta completamente database personalizzati ) perché non dover gestire le credenziali dell'utente e poter delegare tutta la gestione delle password / account utente a Auth0 è una manna dal cielo. Inoltre, questo disaccoppia anche le parti del tuo sistema che sono focalizzate sulla gestione dell'identità di boilerplate rispetto alle parti focalizzate sul business.

Vado con qualsiasi opzione (la più semplice per me da implementare) che mi consenta di eseguire l'unione sul lato server e di visualizzare in una sola operazione una vista normalizzata degli utenti e dei progetti nell'applicazione client .

Ciò consente di mantenere aperte le opzioni, ad esempio, in seguito potresti decidere di sincronizzare le informazioni utente (elementi non credenziali) da Auth0 al tuo database per motivi di prestazioni quando ottieni elenchi di utenti pur sfruttando pienamente il database integrato Auth0 per la gestione dell'identità centrale.