Держаться за предметы после обратной передачи

Question

У меня есть веб-приложение ASP.NET, и я хочу иметь возможность взять элементы из основного списка и временно сохранить их в одном из четырех других списков. «Другие» списки должны сохраняться после постбэков, чтобы к ним можно было добавить больше элементов. В каком направлении вы бы предложили идти?

Я думал об использовании общего списка, хранящегося в памяти, временного хранения элементов в базе данных и обратного вызова их в PostBack, или сохранения их в viewstate, но у меня есть ощущение, что есть какое-то решение, которое я отсутствует, что может быть проще или лучше.

Answer 1

Джош выложил штаты довольно хорошо. Моя рекомендация для меньшего списка, как он сказал, будет использовать состояние сеанса. Использование БД было бы немного беспорядочным, потому что вы должны поддерживать эти временные таблицы и беспокоиться о многосессионном доступе к таблицам. Аналогично, кеш имеет ту же проблему. Viewstate дает вам это с дополнительным трафиком клиента и небезопасными данными. Так что, если вы говорите менее нескольких тысяч экземпляров на сервере с низким трафиком, то сессия, скорее всего, подойдет.

Чтобы облегчить работу с сеансом (и вы можете сделать это с помощью кэширования и состояния приложения), настройте контейнерный объект, который управляет списками.

//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

Первое, что я хотел бы предложить, это посмотреть, сможете ли вы убрать необходимость сохранения состояния в постбэках.

Если вы не можете сделать это (а ViewState неприменимо по некоторым причинам, таким как ограничения пропускной способности или требование сохранения данных даже без обратной передачи из серверной формы), я предлагаю рассмотреть возможность использования Session. Вы можете настроить состояние сеанса так, чтобы он использовал базу данных SQL Server в любое время, не беспокоясь об изменении исходного кода.

Answer 3

Все это варианты, и у всех есть за и против:

База данных:

Хранение элементов в базе данных является довольно простым и последовательным вариантом. Вам действительно нужно беспокоиться о звонке в базу данных в оба конца, но, по крайней мере, у вас есть централизованное расположение для хранения данных, которые легко масштабируются в зависимости от нагрузки на Интернет. Однако, если это недолговечные данные, вам придется беспокоиться об очистке базы данных, поскольку она может стать громоздкой.

Session / Cache:

Сеанс обеспечивает быстрое решение для хранения в памяти, но масштабирование может стать проблематичным, если объем данных очень велик. Чем больше информации вы храните в памяти, тем меньше у вас возможностей для одновременных пользователей. Кроме того, если вы начнете добавлять несколько веб-серверов, вам придется изучить какой-либо сервер состояний сеанса, чтобы пользователи не могли спонтанно потерять свой сеанс.

Кэш имеет в основном все те же плюсы и минусы, за исключением того, что существует дополнительная сложность, связанная с необходимостью следить за тем, чтобы истек срок действия элементов кэша, и управлять проблемами параллелизма.

Опять же, оба эти решения легко внедрить, но они плохо масштабируются при большой нагрузке или больших объемах данных.

ViewState:

Viewstate - это также простое в реализации решение, обеспечивающее загрузку сервера и клиента, но может привести к увеличению времени загрузки для конечного пользователя. Также важно помнить, что ViewState может быть взломан, поэтому, если безопасность является проблемой, вы должны принять дополнительные меры предосторожности для обеспечения целостности данных.

Вывод:

В общем, выясните, чего вы хотите достичь, и выберите решение, которое наилучшим образом соответствует вашим потребностям. Поместите его за какой-нибудь уровень абстракции, например, интерфейс, чтобы потом можно было легко изменить детали, и тогда вам не придется сильно волноваться. Все дело в знании того, что будет работать лучше всего в вашем конкретном сценарии.

Answer 4

Вы можете сохранить список в ViewState или Session и назначить его свойству. Вот простой пример использования общего списка строк, но может быть любого сериализуемого типа.

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

Списки должны автоматически хранить значения, которые они имеют в viewstate. Если они этого не делают, вам, вероятно, нужно включить режим просмотра для этих элементов управления.

Если вы хотите вручную сохранить данные в обоих направлениях, вы можете сохранить их в сеансе или в представлении состояния самостоятельно. Технически состояние взгляда имеет смысл, но если данных много, оно может сделать состояние очень большим и занять много времени, чтобы совершить круговую передачу. Единственная проблема с сессией - вы должны обязательно очистить ее после того, как покинете страницу.

Не используйте базу данных, это не то, для чего она.

Answer 6

Идея базы данных, вероятно, плохая (если вы не имеете дело с большими объемами данных).

Возможно, ваш лучший способ - сохранить основной список в ViewState, а другие списки должны быть списками индексов для первого списка.