Sto cercando di progettare un'applicazione multi-tenant (beh, credo che sia multi-tenant). Abbiamo un'applicazione a singola pagina, un'API e un database comune.
Abbiamo gruppi di utenti, ciascuno con i propri requisiti leggermente diversi. Un utente non può essere in più di un gruppo al momento .
Le caratteristiche principali che abbiamo sono:
- Ricerca: campi di ricerca che variano per gruppo di utenti
- Griglia: colonne che variano per gruppo di utenti
- pannello Dettagli: campi variabili da mostrare per il risultato
Ci sono alcune proprietà comuni in ogni funzione chiave sopra, ma alcune sono completamente uniche per ciascun gruppo.
Ho due considerazioni principali qui:
- Gestione delle visualizzazioni dell'interfaccia utente per gruppo di utenti
- Pubblicando e restituendo al front-end un oggetto con solo le proprietà richieste.
Utilizziamo TypeScript + Angular 1 per il front-end e .NET Web API per il back-end.
Voglio evitare:
- Oggetti di Dio che contengono tutte le proprietà per tutti i gruppi che vanno avanti e indietro sul filo.
- Un sacco di se le istruzioni sono disseminate nel codice front-end per mostrare e nascondere in base al gruppo di utenti.
Con questo in mente, il design attuale che sto considerando è il seguente:
- Carica diverse visualizzazioni per gruppo al momento del caricamento dell'applicazione front-end
- Collega diversi controller in base alla vista
- Attualmente, questo significa che il pacchetto di JS per tutti i gruppi verrà servito al client
- Ciò significa che possiamo avere endpoint specifici per la stessa operazione, che contengono oggetti di richiesta specifici e restituiscono oggetti specifici.
- Dal punto di vista della struttura di una cartella, separa per caratteristica del codice, quindi raggruppa se è diverso.
I vantaggi di questo sono:
- Il codice specifico per un gruppo è facile da ragionare quando differisce
- Pubblicare e ricevere solo ciò che è rilevante per l'utente.
- Se un utente appartiene a più gruppi, possiamo fornire loro una funzionalità per passare tra le mini-applicazioni cambiando il gruppo attivo in cui si trovano.
Gli svantaggi di questo sono:
- Molto più plumbing sul caricamento delle viste e dei controller dipendenti dal gruppo in cui si trova l'utente che ha effettuato l'accesso.
- Serve tutto il codice dell'applicazione front-end per tutti i gruppi in primo piano
- Gestione del deep linking / routing per un gruppo quando un utente appartiene a più gruppi. Suppongo che questo possa essere gestito tramite param querystring. : (
Pensieri?
Aggiornamento 27/07/2017
Quindi, usando un esempio inventato:
I criteri di ricerca variano in base ai diversi campi per gruppo.
-
Group a: Name, Age, DOB, Car type, Car engine size -
Group b: Name, Age, Shoe size, shirt size, favourite colour
Estrapolando questo, abbiamo 8 gruppi, ognuno con 10 proprietà comuni e 5 proprietà specifiche di gruppo. Il mio enigma è il seguente:
Se vado con un singolo endpoint di ricerca con un oggetto di richiesta che incapsula tutte le proprietà per tutti i gruppi. Quelle sono 50 proprietà (10 proprietà comuni + 5 * 8 gruppo).
Per ogni gruppo dato solo 15 sono rilevanti. Devo rendere il codice lato server per utilizzare solo i 15 appropriati e escludere gli altri 35.
Inoltre, lo stesso si verifica sulla risposta. Riceverò un oggetto di grandi dimensioni, di cui solo un piccolo sottoinsieme contiene dati pertinenti all'utente in quel gruppo, il resto è nullo. Dovrò inserire una quantità sufficiente di istruzioni condizionali per gestire la visualizzazione e nascondere queste cose sul lato front-end.
Probabilmente non è considerato multi-tenant, ma sto cercando di ottenere consigli su un buon design per questo tipo di problema.