Approccio alla progettazione di un'app Web del flusso di lavoro che contiene un po 'di automazione

3

Mi è stato affidato il compito di creare un'applicazione web che fornisca agli utenti finali un flusso di lavoro di autoaiuto, ponendo loro domande e saltando in un'altra parte del flusso di lavoro a seconda delle risposte fino alla fine.

Questo va bene, e stavo considerando la creazione di un'applicazione basata sui dati che gli amministratori potevano creare e salvare di nuovo i nuovi flussi di lavoro. Questo sarebbe basato sulle seguenti tabelle DB:

  • Categorie
  • Flussi di lavoro
  • I passaggi
  • Le risposte

Tuttavia, mi è stato ora detto che questi flussi di lavoro conterrebbero alcuni passaggi di controllo automatici, come il controllo di un valore in un DB o un valore della chiave di registro sulla workstation degli utenti o un valore LDAP da Active Directory (adinifinitum annuncio ) contro un valore noto / desiderato (che in alcuni casi sarebbe dinamico). Questo getta completamente una chiave inglese nel lavoro, perché ora sembra che dovrò inserire tutti i flussi di lavoro nell'applicazione, cosa che speravo di evitare.

C'è un modo in cui potrei avvicinarmi a ciò che non vedo, che mi consentirà di continuare a rendere l'applicazione (in qualche modo) guidata dai dati? O è OK / standard per codificare in modo rigido questi tipi di flussi di lavoro in un'app? Il cliente vorrà aggiungere regolarmente nuovi flussi di lavoro, mi viene detto.

Per informazioni, lo svilupperò in C # poiché siamo un negozio di MS.

    
posta Tom Pickles 26.03.2015 - 15:10
fonte

3 risposte

3

Posso pensare a due soluzioni possibili qui, ma entrambe richiedono una buona dose di sviluppo (ma non riesco davvero a vedere una soluzione in cui questo non sia il caso). Raccomando anche non di sviluppare alcun tipo specifico di controllo fino a quando non è effettivamente necessario. È molto facile avere requisiti per 42 diversi tipi di passaggi automatizzati che finiscono per avere solo due o tre di essi effettivamente utilizzati.

Opzione 1: codifica i passaggi

Non è necessario codificare in modo rigido i flussi di lavoro, ma è necessario codificare i passaggi di controllo automatici. Suppongo che la tua struttura di base avrebbe un passo con più risposte e ogni risposta invierà la persona che compila il questionario a un nuovo Step giusto? In tal caso, crei diversi tipi di passaggi.

  • Il passo base sarebbe un "QuestionStep" che ha semplicemente un elenco di possibili risposte che l'utente può definire e aggiungere se stesso, con il passo associato per passare a
  • Un altro passo sarebbe il "DatabaseValueStep" che consentirebbe all'utente di inserire una query da eseguire e definire un elenco di valori che possono essere restituiti, con il passo associato a cui saltare.
  • Un altro passo sarebbe il "LDAPValueStep" che consente all'utente di inserire la proprietà AD per controllare e definire un elenco di valori che possono essere restituiti, con il passo associato a cui saltare.
  • ...

Ogni tipo di passaggio di controllo automatizzato richiede sviluppo.

Opzione 2: invia i dati in una tabella dell'applicazione e controlla che

È possibile definire un sistema dinamico di chiavi e valori che vengono importati in un database. Le chiavi sono dinamiche e possono essere aggiunte al database, dopo di che diventano disponibili nell'applicazione in un CheckStep. Devi creare integrazioni tra altri sistemi e questo sistema per ottenere i tuoi dati, ma scarica il lavoro dall'applicazione del flusso di lavoro ai fornitori di dati.

Ad esempio, puoi avere una tabella PersonData con una colonna "personid", "chiave" e "valore". Un'altra applicazione riempie la tabella con le date di nascita per le persone aggiungendo le righe con la chiave "BirthDate". Un PersonCheckStep nell'applicazione del flusso di lavoro ti consente di definire cosa vuoi fare per la chiave "Data di nascita" e sapere come recuperare i dati. Puoi espandere questo aspetto avendo ComputerData per le impostazioni del PC, LDAPData per le impostazioni LDAP e così via ...

    
risposta data 26.03.2015 - 17:17
fonte
0

La risposta di JDT è abbastanza buona, ma un'altra opzione che potresti prendere in considerazione è una lingua specifica per il dominio ( DSL). In questo approccio definisci un linguaggio semplice per catturare i tuoi flussi di lavoro, fornire primitive per controlli e passaggi specializzati, ecc. E quindi scrivere un motore per interpretarli ed eseguirli.

Tenendo tutto in un database, o hard-coded, si calcifica il sistema e si rende difficile introdurre variazioni nel flusso di lavoro. Usando una lingua, a condizione che la lingua ammetta la ricchezza di cui hai bisogno, devi trasferire la complessità agli script del flusso di lavoro e mantenere il tuo motore pulito e relativamente semplice.

L'aggiunta di ulteriori controlli e passaggi speciali potrebbe essere gestita da qualcosa di simile alle librerie, che forniscono implementazioni in C # per il lavoro speciale richiesto dal DSL. Di nuovo, stai separando il flusso di lavoro principale (nello script DSL), dai controlli e dai passaggi (nelle librerie), dal motore che esegue tutto. Dovrebbe mantenere la complessità gestibile.

Ad esempio, molti videogiochi hanno livelli definiti in un DSL interpretato dal motore di gioco. Permette alle persone prive di forti capacità di programmazione di essere produttive e creare qualcosa di prezioso senza richiedere agli sviluppatori più costosi di implementare tutte le funzionalità di ogni particolare livello.

    
risposta data 26.03.2015 - 17:33
fonte
0

La domanda che dovresti porci è se lo sforzo salvato sulla manutenzione (non dovendo modificare il codice per le future richieste degli utenti) o la versatilità aggiuntiva (come la possibilità di convertire e commercializzare facilmente l'app a diversi utenti) sono vale lo sforzo aggiuntivo di creare un sistema più generalizzato. Non scrivere una fabbrica di distribuzione di condimenti universale quando qualcuno ti chiede di passare il sale.

Un'altra opzione su cui riflettere è assicurarsi che l'architettura possa gestire la personalizzazione, ma innanzitutto creare una versione con hard-disk e preoccuparsi di creare un'interfaccia amministrativa in seguito.

    
risposta data 26.03.2015 - 18:10
fonte