Modo preferito per gestire i dati definiti dal cliente nell'applicazione aziendale

Question

Modo preferito per gestire i dati definiti dal cliente nell'applicazione aziendale

#1 da (2 voti)
#2 da (1 voti)
#3 da (0 voti)
#4 da (0 voti)
#5 da (0 voti)

4

Diciamo che abbiamo un'applicazione web (intranet) di piccole imprese per la gestione dei dati per i concessionari di automobili. Dispone di schermi per la gestione di clienti, inventario, ordini, garanzie e workshop.

Questa applicazione è installata su 10 siti di clienti per diversi rivenditori di automobili.

La prima versione di questa applicazione è stata creata senza alcun modo di fornire dati specifici del cliente. Ad esempio, se il concessionario A voleva essere in grado di allegare una foto a un cliente, il rivenditore B voleva aggiungere un contatto e-mail ad ogni officina e il concessionario C voleva allegare più rapporti PDF a una garanzia, ciascuna caratteristica come questa è stato aggiunto all'applicazione, quindi tutti i clienti hanno ricevuto tutto sul nuovo aggiornamento.

Tuttavia, questo porterà inevitabilmente a conflitti poiché il numero di clienti cresce man mano che i loro schemi di utilizzo sono unici e, se, per esempio, un rivenditore specifico ha richiesto di poter allegare (per qualche motivo) un colore dell'articolo in inventario (ed essere in grado di cercare con questo colore) come elemento richiesto, altri davvero non avrebbero bisogno di questa funzione e sicuramente non vorranno che sia un elemento richiesto. Oppure, un concessionario vorrebbe gestire i contatti e-mail per i propri dipendenti su una schermata separata dell'applicazione.

Immagino che una soluzione per questo sia usare una sorta di sistema di plugin, dove avremmo un nucleo dell'applicazione che fornisce funzionalità standard come clienti, inventario, ecc. e tutti i plugin installati dal cliente.

Esistono diversi tipi di plug-in: schermi standalone come contatti e-mail per i dipendenti, con la loro logica e plug-in per i clienti che estendono o decorano gli articoli dell'inventario (come foto o colori).

I plug-in di inventario (cliente, ordine, ...) richiedono una procedura di installazione, hook per il collegamento all'editor degli articoli, visualizzatore di voci, filtro degli articoli per la ricerca, hook di backup e così via.

È questo il modo giusto per risolvere questo problema?

design-patterns enterprise-architecture

posta Axarydax 01.06.2014 - 13:37

fonte

5 risposte

Leggi altre domande sui tag design-patterns enterprise-architecture

opzioni per l'analisi dei dati per l'archivio delle serie temporali Gestire più flussi di requisiti aziendali senza compromettere le dimensioni del team

score 2 · Answer 1

Molti sistemi hanno una sezione "configurazione" per un rivenditore. Questo è spesso un semplice (dealer_id, name, value) truple in un database. Il codice legge tutto questo e può mostrare / nascondere (o, usando la tecnologia lato server, includere / escludere) alcune opzioni dell'interfaccia utente. Spesso un user_id è legato a dealer_id, quindi sai chi ottiene cosa.

PUOI fare tutto questo con i ruoli degli utenti, ma può diventare confuso in questo modo.

Ho spesso riscontrato che il codice personalizzato consente di distribuire e testare gli incubi. Credo che possa essere fatto con successo, ma sicuramente sembra più semplice attivare e disattivare le cose nelle configurazioni.

Assicurati che le colonne del tuo database siano annullabili o abbiano valori di default decenti, naturalmente.

score 1 · Answer 2

Sei sulla strada giusta. I plug-in forniscono un meccanismo pulito per estendere i dati e le applicazioni principali con dati e logica aziendale specifici del cliente.

Devi architettare il tuo database in modo tale che i dati specifici del cliente possano essere aggiunti a qualsiasi dato fondamentale.

Supponiamo che tu voglia fornire un meccanismo di estensione per i dati dei clienti. Diciamo anche che i dati del cliente principale sono:

1. ID
2. Name (first, last, middle)
3. Address

Potresti aggiungere a questo:

4. Extension

Extension potrebbe includere l'ID del rivenditore e un elenco di nomi di database in cui è possibile trovare i dati dell'estensione.

Nel tuo esempio per il cliente A, puoi creare una tabella per memorizzare le fotografie dei clienti. Quella tabella e la logica per manipolare le fotografie potrebbero essere impacchettate in un plug-in per il client A. Se un altro client richiede la stessa funzionalità, è possibile installare il pacchetto "fotografia del cliente" su di loro.

Poiché i dati di estensione consentono più estensioni, un cliente potrebbe richiedere il numero di plug-in che desidera utilizzare.

Devi gestire la confezione del giusto set di plugin per ogni cliente.

score 0 · Answer 3

All'inizio, svilupperai progetti "personalizzati" per i tuoi clienti esistenti. Una volta che hai una "massa critica" di questi progetti "personalizzati" (per i tuoi clienti originali), sarai in grado di combinare i tuoi disegni per i nuovi clienti. A questo punto, avrà senso avere procedure di installazione specifiche, hook, editor, ecc.

score 0 · Answer 4

0

Sembra che tu debba mettere l'autorizzazione nel tuo sistema. Sviluppa tutte le funzionalità ma metti gli id dei client su ogni servizio / interfaccia utente e in base all'ID client corrente recupera la funzione specifica.

risposta data 01.06.2014 - 17:11

fonte

score 0 · Answer 5

Quando costruisci sistemi modulari devi pensare a come le estensioni saranno autorizzate a manipolare / aumentare i punti di estensione esposti. Questo aggiunge sempre un po 'di complessità a un design, ma quando ben fatto fornisce un prodotto superiore. Pensa a come sono progettati i vari browser per i plugin.

In pratica, costruirò i punti di estensione in base alle necessità al fine di soddisfare le personalizzazioni desiderate. Cioè, invece di estendere semplicemente il tuo software per fare X, considera come fornire un punto di estensione che permetta di collegare X.