ASP.NET; Несколько переменных сеанса или «контейнерный объект»?

Question

У меня есть несколько переменных, которые мне нужно отправить со страницы на страницу ... Как лучше всего это сделать?

Просто отправьте их одну за другой:

string var1 = Session["var1"] == null ? "" : Session["var1"].ToString();
int var2 = Session["var2"] == null ? 0 : int.Parse(Session["var2"].ToString());

и так далее ...

Или поместить их все в какой-нибудь контейнер-объект?

struct SessionData
{
    public int Var1 { get; set; }
    public string Var2 { get; set; }
    public int Var3 { get; set; }
}

-

SessionData data = Session["data"] as SessionData;

Какое лучшее решение?Что вы используете?

Answer 1

Гибрид из двух является наиболее приемлемым подходом. Session предлагает гибкое хранилище пар ключ-значение с низким импедансом, поэтому было бы расточительно не воспользоваться этим. Однако для сложных фрагментов данных, которые всегда связаны друг с другом - например, UserProfile - имеет смысл иметь глубоко вложенный объект.

Answer 2

Если все данные, которые вы храните в сеансе, связаны, то я бы посоветовал объединить их в один объект, как ваш второй пример:

public class UserData
{
    public string UserName { get; set; }
    public string LastPageViewed { get; set; }
    public int ParentGroupId { get; set; }
}

И затем загрузить все один раз и сохранитьдля сеанса.

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

Answer 3

Я использую SessionHandler, который представляет собой пользовательский свернутый класс, который выглядит следующим образом

public static class SessionHandler
{
    public static string UserId
    {
        get
        {
            return Session["UserId"];
        }
        set
        {
            Session["UserId"] = value;
        }
    }    
}

А затем в коде я делаю

var user = myDataContext.Users.Where(u => u.UserId = SessionHandler.UserId).FirstOrDefault();

Answer 4

Большой плюс объекта: свойства строго типизированы.

Answer 5

Я использовал оба. В общем, многие имена переменных сеанса приводят к возможности коллизий, что делает коллекции более надежными. Убедитесь, что содержание коллекции относится к одной ответственности, так же, как и к любому объекту. (На самом деле, бизнес-объекты являются отличными кандидатами для объектов сеанса.)

Два совета:

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

Во-вторых, убедитесь, что каждый объект помечен атрибутом [Serializable]. Если вам когда-либо понадобится сохранить состояние сеанса вне процесса, это очень важно.

Answer 6

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