Retenir des articles après une publication

Question

J'ai une application web ASP.NET et je veux être en mesure de prendre des articles d'une liste principale et de les stocker temporairement dans l'une des quatre autres listes. Les listes 'autres' doivent survivre aux post-retours afin que d'autres éléments puissent y être ajoutés. Dans quelle direction suggéreriez-vous d'aller avec? J'ai pensé à utiliser une liste générique stockée en mémoire, en stockant temporairement les éléments dans la base de données et en les rappelant sur PostBack, ou en les stockant dans le viewstate, mais j'ai le sentiment qu'il y a une solution m manquant qui pourrait être plus facile ou mieux.

Answer 1

Josh a très bien décrit les états. Ma recommandation pour une liste plus petite comme il a dit utiliserait l'état de session. L'utilisation de la base de données serait un peu compliquée car vous devez gérer ces tables temporaires et vous inquiéter de l'accès multi-session aux tables. De même, le cache a le même problème. Viewstate vous offre cela avec un trafic client supplémentaire et des données non sécurisées. Donc, si vous parlez moins de quelques milliers d'instances sur un serveur à faible trafic, la session est probablement bonne. Pour faciliter l'utilisation de la session (et vous pouvez le faire avec la mise en cache et l'état de l'application), configurez un objet conteneur qui gère les listes.

//To use it in your page, you can easily access it via: 

ListManagerContext.Current.MasterList.Add(4); 


[Serializable] 
public class ListManagerContext 
{ 
    public List<int> MasterList { get; set; } 
    public List<int> SubList1 { get; set; } 
    public List<int> SubList2 { get; set; } 
    public List<int> SubList3 { get; set; } 


    /// <summary> 
    /// Key used for the list manager context session variable. 
    /// </summary> 
    public const string ListManagerContextKey = "ListManagerContext"; 

    /// <summary> 
    /// Gets the current ListManagerContext for this session. 
    /// If none exists, it returns a brand new one. 
    /// </summary> 
    [XmlIgnore] 
    public static ListManagerContext Current 
    { 
     get 
     { 
      HttpContext context = HttpContext.Current; 

      if (context != null && context.Session != null) 
      { 
       ListManagerContext data = null; 
       if (context.Session[ListManagerContextKey] == null) 
       { 
        data = new ListManagerContext(); 
        context.Session[ListManagerContextKey] = data; 
       } 
       else 
        data = context.Session[ListManagerContextKey] 
            as ListManagerContext; 

       return data; 
      } 
      throw new ApplicationException(" 
        No session available for list manager context."); 
     } 
    } 
} 

Answer 2

L'idée de la base de données est probablement mauvaise (en supposant que vous n'ayez pas affaire à de grandes quantités de données).

Peut-être votre meilleure méthode serait de stocker la liste principale dans ViewState, et ont les autres listes sont des listes d'index à la première liste.

Answer 3

Les listes doivent stocker automatiquement les valeurs dont elles disposent dans viewstate. Si ce n'est pas le cas, vous devez probablement activer viewstate pour ces contrôles.

Si vous souhaitez que les données survivent à l'aller-retour, vous pouvez les stocker vous-même dans la session ou dans viewstate. Techniquement, viewState a le plus de sens, mais s'il y a beaucoup de données, cela peut rendre le viewstate très volumineux et prendre beaucoup de temps pour faire un aller-retour. Le seul problème avec la session est que vous devrez vous assurer de l'effacer une fois que vous quittez la page. N'utilisez pas la base de données, ce n'est pas ce à quoi elle sert.

Answer 4

Vous pouvez stocker la liste dans ViewState ou Session et l'affecter à une propriété. Voici un exemple simple utilisant une liste générique de chaîne, mais peut être n'importe quel type sérialisable.

private List<String> MyTempList 
{ 
    get{return Session["mylist"] as List<String>;} 
    set{Session["mylist"] = value;} 
} 

protected void Page_Load(object source, EventArgs e) 
{ 
    if(!IsPostBack) 
    { 
    MyTempList = new List<String>(); 
    } 
    else 
    { 
    MyTempList.Add("Something"); 
    } 
} 

Answer 5

La première chose que je suggère est de voir si vous pouvez supprimer le besoin de conserver l'état à travers les publications.

Si vous ne pouvez pas le faire (et ViewState n'est pas applicable pour une raison quelconque, comme les limitations de bande passante ou la conservation des données même sans publication d'un formulaire serveur), je suggère d'utiliser Session. Vous pouvez configurer l'état de session pour utiliser un backend de base de données SQL Server quand vous le souhaitez sans vous soucier de la modification du code source.

Answer 6

Tous ces éléments sont les options et tous ont pro et contre:

Base de données:

Stockage des éléments dans la base de données est une option assez facile et cohérente. Vous devez vous soucier de faire un appel aller-retour à la base de données, mais au moins vous disposez d'un emplacement centralisé pour raconter les données qui s'adapteront facilement à votre charge Web. Cependant, s'il s'agit de données de courte durée, vous devrez vous soucier de nettoyer votre base de données, car cela pourrait devenir difficile.

Session/Cache:

session offre une solution rapide pour le stockage en mémoire, mais mise à l'échelle peut devenir problématique si la quantité de données est très grande. Plus vous stockez d'informations en mémoire, moins vous disposez de capacité pour les utilisateurs simultanés. En outre, si vous commencez à ajouter plusieurs serveurs Web, vous devrez vous tourner vers un serveur d'état de session pour vous assurer que les utilisateurs ne perdent pas spontanément leur session.

Cache a essentiellement les mêmes avantages/inconvénients, sauf qu'il y a la complexité supplémentaire de devoir s'assurer que vous expirez des éléments de cache, et de gérer les problèmes de concurrence.

Encore une fois, ce sont des solutions faciles à mettre en œuvre, mais qui ne s'adaptent pas aussi bien sous une charge importante, ou de grandes quantités de données.

ViewState:

Viewstate est également facile à mettre en œuvre la solution et obtient la charge le serveur et dans le client, mais peut entraîner des temps de chargement plus longs pour l'utilisateur final. En outre, il est important de se rappeler que ViewState peut être piraté, donc si la sécurité est une préoccupation, alors vous voulez prendre des précautions supplémentaires pour assurer l'intégrité des données.

Conclusion:

Dans l'ensemble, savoir ce que vous voulez accomplir et choisir la solution qui correspond le mieux à vos besoins. Poussez-le derrière une couche d'abstraction comme une interface afin que vous puissiez facilement modifier les détails plus tard, et vous n'aurez plus à vous inquiéter. Il s'agit de savoir ce qui fonctionnera le mieux dans votre scénario particulier.