Best practice per il flusso di lavoro delle applicazioni Web?

Question

Nota: dal flusso di lavoro non mi riferisco alla tecnologia del flusso di lavoro, come la base del flusso di lavoro.

Troppo spesso mi viene richiesto di progettare pagine che passano attraverso una serie di passaggi.

1) Selezionare da un set di opzioni. Sottoscrivi. 2) Compila una pagina con i risultati. Fare cambiamenti. Sottoscrivi. 3) Fai qualcosa in base ai risultati precedenti. Sottoscrivi. 4) Confermare le azioni precedenti. Sottoscrivi. 5) Goto 1.

Un sito di e-commerce con carrello della spesa sarebbe un esempio da manuale.

Ora, ci sono diversi modi per affrontare questo. La mia domanda è, qual è il modo consigliato di farlo in asp.net? In PHP o ISAPI userei solo i controlli html standard, ottenere i dati dei post e fare cose con essi, ognuno su una pagina diversa.

ASP.NET sembra essere più orientato verso soluzioni a pagina singola. Fai il tuo lavoro, postback a te stesso, quindi visualizza i risultati nella stessa pagina .. spostandoti fino alla fine, usando qualcosa come MultiView o UpdatePanels per fare il lavoro. Ma la chiave è che non si effettua il postback su un'altra pagina.

Ora capisco che Microsoft ha aggiunto i postback di pagine incrociate a .NET nelle versioni recenti, ma questo sembra meno cotto e un po 'ingombrante. È difficile lavorare con i dati che sono stati postati indietro a meno che non li esponi tramite proprietà o qualcosa della tua pagina precedente.

Come gestisci lo scenario che ho esposto sopra? Usi un multi-view o updatepanel e fai tutto in un'unica pagina? O lo fai in più pagine? Quali sono le tue migliori pratiche in questo senso? Hai qualche disegno specifico che tendi ad usare? Come procedi nel strutturare il flusso di lavoro dei siti?

Answer 1

ci sono una serie di modi di farlo (oltre multi-view):

1, asp.net dose di assistenza post azione, Goggle Page.Request.Form[item]http://msdn.microsoft.com/en-us/magazine/cc164151.aspx#S3

2, è possibile salvare i dati temporanei in tabella temporanea del database, quindi quando gli utenti passano attraverso ogni pagina, tutto ciò che devono fare è fare riferimento all'ID dei dati temporanei nel database. (Stringa di query)

3, sarà inoltre possibile salvare i dati temporanei come oggetto nella sessione, in modo che tutte le pagine nel "flusso di lavoro" possano fare riferimento alla sessione, quindi eseguire la manipolazione in base ad essa.

dopo tutto, hanno tutti pro e contro, dipende principalmente da quanto complessi sono i requisiti del progetto.

Answer 2

Per questi tipi di situazioni, ho utilizzato più controlli del pannello per contenere i vari passaggi del processo. Imposta la proprietà visible per visualizzare l'interfaccia utente per la porzione che vuoi che l'utente veda.

Si potrebbe anche voler guardare il Wizard Web Server Control che gestisce l'impianto idraulico per la navigazione tra i passaggi del processo. Per avere qualche idea su come funziona il controllo, dai un'occhiata a The ASP.NET 2.0 Wizard Control.

Answer 3

Mystere Man, ho letto la tua domanda come chiedendo come lo facciamo. Per me, ho una parola: Contesto. Tenerlo nel contesto. Spiegherò.

Se lo desideri, puoi creare un'intera applicazione Web da una sola pagina.Tecnicamente è possibile anche se sarebbe tanto disorientante quanto uscire. Raggruppo le mie funzionalità in parti logiche come "Selezione di un prodotto". Ero solito creare una singola pagina che raggruppava il processo "Checking Out", ma scoraggiavo il fatto che ora il mio team ha dovuto saltare nel processo in punti specifici come aggiungere automaticamente prodotti al carrello e quindi visualizzare la pagina finale nel processo di check-out (pensa di ottenere un download gratuito: non hai bisogno di informazioni sulla spedizione, sulla fatturazione o sul loro nome). Con la tua lista numerata qui sopra, se è tutta sulla feature, allora la renderei una pagina fisica, ma la spezzerei in più pagine se si scopre che devo "saltare dentro" il flusso. Se lo crei una pagina, hai bisogno di limiti chiari.

Non uso cross-posting. Mi piace usare controller multiview. Per me, è importante identificare chiaramente ciò che ciascuna vista ha bisogno perché sia ​​attiva. Nel mio evento di caricamento della pagina, ho una chiamata al metodo che esamina le variabili o i cookie di querystring o di sessione (questi sono i contenitori del mio stato) e, in base a ciò che è impostato, attivo una vista. Non c'è più codice nel caricamento della pagina, invece, utilizzo l'evento load della vista come pseudo caricamento della pagina. Codigo qualunque cosa si suppone che la vista specifica faccia.

Con questo approccio, penso pattern MVC di ASP.NET è dove devo andare.