Modelli di archiviazione dei dati per il salvataggio intermedio di un modulo del flusso di lavoro basato sul Web

Question

Modelli di archiviazione dei dati per il salvataggio intermedio di un modulo del flusso di lavoro basato sul Web

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

1

Sfondo: sto sviluppando un modulo web basato su procedura guidata in cui gli utenti possono accedere a un riempimento in alcuni dettagli e premere avanti e indietro per andare avanti e indietro nella procedura guidata prima che vengano effettivamente inviati. Quando l'utente inoltra, effettuo una chiamata di servizio che esegue alcuni processi sui dati.

Problema: Non tutti i dati sono disponibili prontamente all'utente, e l'utente può scegliere di "salvare" i dati invece di "inviarli" e poi tornare (se sceglie a) e finirlo più tardi. Questi dati intermedi sarebbero incompleti (e in alcuni casi non validi), ma per praticità lasceremo che l'utente li salvi.

Soluzioni che ho visto in passato: In passato mi sono occupato di questo con 2 soluzioni distinte -

Salva i dati intermedi nelle tabelle normali (dove i dati inviati vengono salvati) e contrassegna tali dati come "inattivi". I dati verrebbero "attivati" d solo quando l'utente fa clic su invia e tutti i dati sono validi. Ciò comporta la modifica del servizio che viene richiamato per accettare i dati sul salvataggio dei dati intermedi e non validi. Inoltre questo pone l'onere sul team di ricordare di controllare il flag "attivo" in ogni query.
L'altra opzione è quella di memorizzare i dati salvati intermedi in enormi CLOB denormalizzati. I dati potrebbero essere strutturati all'interno dei CLOB come XML o JSON. I dati intermedi (salvati) sono completamente disgiunti dal completamento (inviato). Il lato negativo è che ora il modulo deve essere in grado di lavorare con 2 diversi set di servizi in base allo stato del ciclo del flusso di lavoro (se in corso leggere l'XML dal CLOB - se completato leggere dal servizio che ha dati validi !)

Domanda: Esiste un modo migliore per risolvere questo problema poiché sembra un problema universale nel mondo aziendale, almeno? Qualcuno potrebbe indicarmi qualsiasi "schema" di archiviazione o di dati che la comunità ha seguito per risolvere questo problema di archiviazione nei flussi di lavoro Web?

Nota: La tecnologia di database sottostante può essere pensata per un sistema che supporta le tabelle e i singoli campi possono contenere stringhe molto grandi come i CLOB.

workflows webforms storage date-patterns

posta Yazad Khambata 06.04.2015 - 19:05

fonte

2 risposte

Leggi altre domande sui tag workflows webforms storage date-patterns

Progettazione dell'API per app modulari Come mantenere l'atomicità con un modello di servizio simile

score 1 · Answer 1

Dato che stai progettando un sito web, ci sono più opzioni e la selezione dipende chiaramente dalle tue esigenze.

Salva nel lato client

potresti utilizzare i cookie o la memoria locale per ottenere questo, il vantaggio principale di questo è che non devi inviare e recuperare i dati da e verso il server per persistere.

Tuttavia non sarai in grado di riprendere il tuo lavoro da un altro client.

Salva sul lato server

Persistendo i dati nelle stesse tabelle e contrassegnandoli come inattivi si otterrà l'accumulo di dati non validi nel sistema quando l'utente decide di abbandonare il flusso di lavoro. Ma ancora una volta questo può essere eliminato se l'utente è costretto a continuare oa cancellare il flusso di lavoro completato a metà quando l'utente tenta di utilizzare il flusso di lavoro. Uno dei vantaggi di questo è che sarebbe soggetto a un minor numero di errori di persistenza poiché è già presente nel database. Tuttavia, ciò potrebbe non funzionare a seconda della struttura del database.

Il salvataggio dei dati in formato XML o JSON sul server richiede una logica aggiuntiva e, a seconda del flusso di lavoro, potrebbe essere complicato da implementare (come la conversione dal modello XML / JSON al modello di dominio).

score 0 · Answer 2

abbiamo dovuto implementare un "tunnel di sottoscrizione" per raccogliere e filtrare potenziali clienti dal Web, implementando un flusso di lavoro di sottoscrizione.

Ciò che abbiamo fatto è implementare un modello di "fornitore". Dietro questo schema avevamo tutti i dati del flusso di lavoro da memorizzare in una singola tabella (e altamente de-normalizzata). Ciò è stato fatto per semplificare il "costo di elaborazione" del provider e per consentire di riorganizzare le fasi del flusso di lavoro su richiesta. Questa tabella rappresenta tutti i dati "raccoglibili". Lo abbiamo fatto usando MSSQLServer. Non posso dire che questa scelta tecnica fosse la migliore per noi, ma ha funzionato e i nostri uomini d'affari hanno trovato agilità riguardo a questa parte strategica del sistema. Il provider potrebbe essere collegato ai file di configurazione con una semplice Iniezione delle dipendenze.