Design Pattern per saltare i passaggi in un Wizard

3

Sto progettando un sistema flessibile Wizard che presenta un numero di schermate per completare un'attività. Potrebbe essere necessario saltare alcune schermate in base alle risposte ai prompt su una o più schermate precedenti.

Le condizioni per saltare una determinata schermata devono essere modificabili da un utente non tecnico tramite un'interfaccia utente. È necessario combinare più condizioni solo con and .

Ho in mente un progetto iniziale, ma mi sembra inelegante. Mi chiedo se c'è un modo migliore per affrontare questa classe di problemi.

Design iniziale

UI

dove

La prima colonna consente all'utente di selezionare una domanda da una schermata precedente.

La seconda colonna consente all'utente di selezionare un operatore applicabile al tipo di domanda posta.

La terza colonna consente all'utente di inserire uno o più valori a seconda dell'operatore selezionato.

Modello oggetto

public enum Operations { ... }
public class Condition
{
    int QuestionId { get; set; }
    Operations Operation { get; set; }
    List<object> Parameters { get; private set; }
}

List<Condition> pageSkipConditions;

Logica controller

bool allConditionsTrue = pageSkipConditions.Count > 0;
foreach (Condition c in pageSkipConditions)
{
    allConditionsTrue &= Evaluate(previousAnswers, c);
} 

// ...

private bool Evaluate(List<Answers> previousAnswers, Condition c)
{
    switch (c.Operation)
    {
        case Operations.StartsWith:
            // logic for this operation
        // etc.
    }
}
    
posta Eric J. 11.07.2012 - 05:03
fonte

2 risposte

3

Bene, c'è un modello formale da Fowler che descrive ciò che stai facendo bene qui . L'ho usato per progettare maghi che avevano anche rami (anche se ricordo che la sua descrizione / documentazione di quel modello è molto meglio).

Detto questo, se fai un passo indietro e veramente guarda ciò che stai descrivendo ... sembra notevolmente come una macchina a stati. Quelli sono ben documentati in molti posti ma vengono in sapori diversi attraverso dettagli di implementazione. I più notevoli di quelli:

  • controllo centrale ie. alcune classi gestiscono la logica di transizione dello stato (questo è simile a quello che hai già progettato)
  • controllo distribuito ie. ogni stato conosce le transizioni che lo lasciano e chiama un cambiamento di stato sul genitore di cui implementano lo stato
risposta data 11.07.2012 - 15:03
fonte
1

Un miglioramento:

Basta avere un metodo in Condition.evaluate(List<Answers> previous) e implementare la logica lì, poiché dovrebbe essere invariato. Scratch l'istruzione switch.

Un altro commento: potresti prendere in considerazione la possibilità di consentire più condizioni per ID di domanda. nel modello corrente avrai difficoltà a saltare a domande diverse in base a criteri (ad esempio, passa a 34 se inserisco < 4, passa a 92 altrimenti, ecc.). Potresti anche considerare di far sì che le condizioni facciano parte della domanda o di qualche oggetto di mediazione (le condizioni delle domande o quello che hai)

Altrimenti mi sembra buono, scrivere maghi fa schifo, tenerlo nel modo più semplice possibile.

    
risposta data 11.07.2012 - 08:54
fonte

Leggi altre domande sui tag