DesignPatterns: qual è il più appropriato da utilizzare per un'interfaccia utente in stile procedura guidata?

Question

Sto implementando un'interfaccia utente in stile Wizard. Mentre un utente scorre attraverso la procedura guidata, facendo clic su Avanti, a seconda delle scelte che hanno scelto su ciascuna schermata, l'utente dovrà passare attraverso un certo insieme di schermate della procedura guidata.

Questo è in fase di creazione in ASP.NET MVC. Mi chiedo quale modello di progettazione sarebbe più adatto per implementare la logica della sequenza di passaggi che si trovano nella procedura guidata. Di nuovo, hanno più percorsi attraverso la procedura guidata a seconda delle scelte che fanno.

Posso utilizzare un elenco collegato? "Command Design Pattern"? Che cosa mi consiglia?

Per dirla in un altro modo: Dove/Come si astraggono/incapsulano la logica di determinare qual è il prossimo passo della procedura guidata in base a ciò che l'utente ha scelto in un particolare passaggio della procedura guidata?

Answer 1

Per dirla in un altro modo: Dove/Come si astraggono/incapsulano la logica di determinare qual è il prossimo passo della procedura guidata in base a ciò che l'utente ha scelto in un particolare passaggio della procedura guidata?

Un modo per farlo sarebbe quello di modellare le classi Wizard, Step e Product. Forse qualcosa del genere?

public class Wizard 
{ 
    public Step forward() {//...} 

    public Step backward() {//...} 

    public Step current() {//...} 

    public Product getProduct() {//...} 
} 

public class Step 
{ 
    public String name() {//...} 

    public void commit(Product product) {//...} 

    public void rollback(Product product) {//...} 
} 

public class Product 
{ 
    //... 
} 

Lo scopo del Wizard è quello di creare un prodotto (auto, computer, vacanze, ecc.).

In questo scenario, è la procedura guidata che decide il passaggio successivo, forse in base allo stato del prodotto che la procedura guidata sta creando. Il Wizard si comporta come un Builder sotto il controllo dell'interfaccia utente, che sarebbe il Director e la procedura guidata per indicare quando e in che direzione effettuare una transizione. Spetta al Wizard decidere quale sarà il prossimo passo. Potrebbero essere supportati più punti di divisione, ma tale implementazione verrà nascosta all'interno della procedura guidata.

Il passo sarebbe un'istanza di Command Pattern con funzionalità di annullamento/ripristino.

Answer 2

Il modello "State" potrebbe avere senso se si desidera consentire all'utente di spostarsi avanti e indietro nella procedura guidata.

Un motivo del flusso di lavoro potrebbe anche avere senso. Forse indagare utilizzando la base di Windows Workflow.

Answer 3

Sono d'accordo con Beau.

In realtà, se hai bisogno di un insieme complesso di regole per la logica di navigazione, allora hai una GUI guidata, ma non una procedura guidata sotto il cofano.

Se ciò che si sta tentando di costruire è in realtà un mago, ogni schermata dovrebbe scorrere al massimo in 2-3 schermi diversi (IMO). Questo potrebbe essere memorizzato facilmente in una struttura molto semplice (database, file di configurazione statico).

Answer 4

Mi piace mantenerlo semplice. Ho impostato un valore sull'oggetto che sto costruendo con un numero di passo, quindi se sto costruendo una polizza assicurativa avrei una proprietà sulla politica che indica in quale fase si trova. Poi ho un singolo metodo che è il router e guarda il criterio e determina dove inviarlo, puoi costruire una logica extra nel router per saltare i passaggi oppure puoi mettere la logica in ogni metodo passo e reindirizzare al router metodo.