2010-01-04 11 views
7

Ho creato un'app ASP.NET MVC qualche tempo fa e dopo alcuni cicli di manutenzione mi chiedo se ho adottato l'approccio migliore per la gestione dello stato. Tutto funziona, ma ho la sensazione che ci sia un modo migliore.Gestione dello stato in ASP.NET MVC

Il sito è basato su una funzionalità di ricerca che ha diverse opzioni. Un utente inizia a utilizzare il sito compilando un numero di opzioni di ricerca in un modulo e facendo clic sul pulsante 'cerca'. Questo pulsante messaggi al metodo di ricerca con tutte le opzioni di ricerca in corso di definizione come parametri ai metodi di ricerca, come ad esempio:

public ActionResult Search(string param1, string param2, string param3, int? param3, long? param4) 

Ora la pagina dei risultati che si presenta ha un numero di link su di esso, portando a varie pagine di dettaglio , ecc Dal momento che ho bisogno lo stato di ricerca da conservare nella pagina di dettaglio, mi ritrovo a creare ActionLinks con un sacco di parametri di tutto il luogo, come ad esempio:

<%=Html.ActionLink("LinkText", "MethodName", new {id="idOfDetailPage", param1=Model.param1, param2=Model.param2, param3=Model.param3, param4=Model.param4}, null)%> 

la maggior parte dei valori dei parametri in ogni link do non cambiare dallo stato attuale della ricerca, ma ho bisogno di passarli per poter creare altri link nella pagina di dettaglio con la c parametri di ricerca urrent, come ad esempio "torna ai risultati di ricerca".

Quando ho bisogno di aggiungere un parametro di ricerca a causa di una nuova richiesta di funzionalità, mi trovo a modificare molti link e tutti i metodi di controllo a cui i collegamenti conducono. Questo è dove sento che ho bisogno di un modo migliore.

Ho pensato di utilizzare lo stato di sessione per mantenere i parametri di ricerca, ma per qualche ragione ho pensato che non era la cosa migliore da usare in ASP MVC e quindi sono curioso di sapere se esiste un altro modo più semplice per farlo.

Nota: Ho anche provato un approccio in cui utilizzo un oggetto fortemente tipizzato in ActionLink ma devo ancora passare i parametri a quell'oggetto in modo che non diventi molto migliore.

Tutte le idee sono apprezzate.

risposta

1

L'utilizzo dello stato di sessione per questo tipo di cose è sempre un fastidio perché significa che queste pagine non possono essere contrassegnate e se si desidera avere più di una scheda aperta inizia a diventare disordinato.

si potrebbe creare una nuova classe SearchParameters:

public class SearchParameters 
{ 
    public string Param1 { get; set; } 
    public string Param2 { get; set; } 
} 

modificare la vostra azione per essere

public ActionResult Search(SearchParameters params) 

e poi passare questo di nuovo alla vista attraverso i dati della vista.

la visualizzazione dovrebbe quindi essere in grado di utilizzare

<%=Html.ActionLink("LinkText", "MethodName", Model) %> 

Se stai usando questo in tutto il luogo, come si potrebbe creare un'estensione HtmlHelper:

public static class SearchExtensions 
{ 
    public static string SearchLink<TModel>(this HtmlHelper<TModel> helper, string linkText) 
     where TModel : SearchModel, class //required by ASP.NET MVC 
    { 
     return helper.ActionLink(linkText, "MethodName", modelType.ViewData.Model) %> 
    }  
} 

e quindi la ricerca è semplice come:

<%=Html.SearchLink("LinkText") %> 
+0

Questo funziona fintanto che passo sempre gli stessi parametri di ricerca e solo i parametri di ricerca all'atto ion, come l'azione di ricerca. Tuttavia ho problemi quando devo passare altri dati all'azione, come l'ID di un oggetto (come per una pagina di dettaglio).Quindi non posso semplicemente passare il modello al metodo helper Html.ActionLink. Inoltre, molti link richiedono che uno dei parametri di ricerca venga modificato, mentre il resto rimane lo stesso, quindi con questo approccio devo continuare a creare nuovi oggetti SearchParameters. Funziona ma dopo un po 'diventa caotico. –

+3

Sto per attaccare il mio remo e suggerisco che le ricerche nei bookmarking non sono sempre una buona cosa da fare, dipende piuttosto dal contesto e dall'applicazione - questo è particolarmente vero se la ricerca ha dipendenze che non sono esposte nei parametri. Detto questo, penso che questa sia una buona generalizzazione (-: – Murph

Problemi correlati