Последовать за тем, что сказали другие. Я склонен иметь два слоя:
базовый слой. Это в DLL, который добавляется почти ко всем проектам веб-приложения . В этом у меня есть класс SessionVars, который делает трудную работу для методов get/методов set Состояния сеанса. Это содержит код как следующее:
public class SessionVar
{
static HttpSessionState Session
{
get
{
if (HttpContext.Current == null)
throw new ApplicationException("No Http Context, No Session to Get!");
return HttpContext.Current.Session;
}
}
public static T Get<T>(string key)
{
if (Session[key] == null)
return default(T);
else
return (T)Session[key];
}
public static void Set<T>(string key, T value)
{
Session[key] = value;
}
}
Примечание дженерики для получения любого типа.
я тогда также добавляю Методов get/методы set для определенных типов, особенно представляю в виде строки, так как я часто предпочитаю работать со строкой. Пустой, а не пустой для переменных, представленных Пользователям.
, например:
public static string GetString(string key)
{
string s = Get<string>(key);
return s == null ? string.Empty : s;
}
public static void SetString(string key, string value)
{
Set<string>(key, value);
}
И так далее...
я тогда создаю обертки, чтобы абстрагировать это далеко и принести ему до прикладной модели. Например, если у нас есть потребительские детали:
public class CustomerInfo
{
public string Name
{
get
{
return SessionVar.GetString("CustomerInfo_Name");
}
set
{
SessionVar.SetString("CustomerInfo_Name", value);
}
}
}
Вы разбираетесь в идее?:)
ПРИМЕЧАНИЕ: Просто имел мысль при добавлении комментария к принятому ответу. Всегда удостоверяйтесь, что объекты являются сериализуемыми при хранении их на Сессии при использовании сервера состояния. Может быть слишком легко попытаться сохранить объект с помощью дженериков, когда на веб-ферме и это идет бум. Я развертываюсь на веб-ферме на работе так добавленные проверки к моему коду в базовом слое, чтобы видеть, является ли объект сериализуемым, другое преимущество инкапсуляции Методов get Сессии и Методов set:)
Это в значительной степени, как Вы делаете это. Однако существует более короткий синтаксис, который можно использовать.
sSession = (string)Session["variable"] ?? "set this";
Это говорит, являются ли переменные сеанса пустыми, сессия набора для "установки этого"
Это может сделать вещи более изящными для обертывания его в свойство.
string MySessionVar
{
get{
return Session["MySessionVar"] ?? String.Empty;
}
set{
Session["MySessionVar"] = value;
}
}
тогда можно рассматривать его как строку.
if( String.IsNullOrEmpty( MySessionVar ) )
{
// do something
}
'Поскольку' нотация в c# 3.0 является очень чистой. Так как все переменные сеанса являются nullable объектами, это позволяет Вам захватить значение и поместить его в Вашу собственную переменную определенного типа без беспокойства выдачи исключения. Большинство объектов может быть обработано этот путь.
string mySessionVar = Session["mySessionVar"] as string;
Мое понятие - то, что необходимо вытянуть Переменные сеанса в локальные переменные и затем обработать их соответственно. Всегда предполагайте, что Ваши Переменные сеанса могли быть пустыми и никогда не бросать их в не допускающий NULL-значения тип.
при необходимости в не допускающей NULL-значения переменной определенного типа можно тогда использовать TryParse для получения этого.
int mySessionInt;
if (!int.TryParse(mySessionVar, out mySessionInt)){
// handle the case where your session variable did not parse into the expected type
// e.g. mySessionInt = 0;
}
Проверка ничто/Пустой указатель является способом сделать это.
Контакт с типами объектов не является способом пойти. Объявите строгий тип и попытку бросить объект к корректному типу. (И используйте бросок, подсказывают или Преобразовывают)
private const string SESSION_VAR = "myString";
string sSession;
if (Session[SESSION_VAR] != null)
{
sSession = (string)Session[SESSION_VAR];
}
else
{
sSession = "set this";
Session[SESSION_VAR] = sSession;
}
Извините за любые нарушения синтаксиса, я - ежедневный VB'er
Обычно я создаю SessionProxy со свойствами со строгим контролем типов для объектов на сессии. Код, который получает доступ к этим проверкам свойств на ничтожность и делает кастинг к надлежащему типу. Хорошая вещь об этом состоит в том, что все мои связанные с сессией объекты сохранены в одном месте. Я не должен волноваться об использовании различных ключей в различных частях кода (и удивление, почему это не работает). И с внедрением зависимости и насмешкой я могу полностью протестировать его с модульными тестами. Если следует за принципами DRY и также позволяет мне определить разумные значения по умолчанию.
public class SessionProxy
{
private HttpSessionState session; // use dependency injection for testability
public SessionProxy( HttpSessionState session )
{
this.session = session; //might need to throw an exception here if session is null
}
public DateTime LastUpdate
{
get { return this.session["LastUpdate"] != null
? (DateTime)this.session["LastUpdate"]
: DateTime.MinValue; }
set { this.session["LastUpdate"] = value; }
}
public string UserLastName
{
get { return (string)this.session["UserLastName"]; }
set { this.session["UserLastName"] = value; }
}
}
Мне также нравится обертывать переменные сеанса в свойства. Методы set здесь тривиальны, но мне нравится писать получить методы, таким образом, у них есть только одна точка выхода. Чтобы сделать это, я обычно проверяю на пустой указатель и устанавливаю его на значение по умолчанию прежде, чем возвратить значение переменной сеанса. Что-то вроде этого:
string Name
{
get
{
if(Session["Name"] == Null)
Session["Name"] = "Default value";
return (string)Session["Name"];
}
set { Session["Name"] = value; }
}
}
Вы используете.NET 3.5? Создайте метод расширения IsNull:
public static bool IsNull(this object input)
{
input == null ? return true : return false;
}
public void Main()
{
object x = new object();
if(x.IsNull)
{
//do your thing
}
}
Если Вы знаете, что это - строка, можно использовать Строку. IsEmptyOrNull () функция.