2008-12-03 2 views
0

Я создаю веб-приложение, которое использует внешний класс для обработки большей части работы и правил для сайта. Для большинства страниц потребуется доступ к этому классу, чтобы получить необходимую информацию. Раньше я бы поставил такой класс в переменную сеанса, поэтому он легко доступен по мере необходимости и не должен постоянно повторяться.Лучшая практика для поддержания класс (-ов) класса

Первый вопрос, это плохая идея, чтобы наполнить этот класс переменной сеанса (она не очень большая)?

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

ответ

0

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

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

3

Прежде чем принять решение о том, где хранить свой класс, вы должны ответить на два вопроса:

  1. Как долго этот класс должен жить?
  2. В каком объеме он должен быть виден?

Примеры, которые отвечают на оба вопроса: запрос, сеанс пользователя, приложение.

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

Теперь, после того как вы определили продолжительность жизни, у вас есть несколько решений. Лучшим решением для управления стилем жизни является контейнер IoC. Более простым решением является просто абстрактное хранилище и использование статического фасада, например Current.MyClass, где экземпляр MyClass хранится в запросе, сеансе или приложении в зависимости от того, какое хранилище было предоставлено Current.

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

0

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

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

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

Первый был в Code Project Это может быть второй link

Шаблон легко и прямо вперед. Я также создал класс для запросов на захват параметров из строк запросов url. Я не вижу причин не распространять его на файлы cookie.

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

using System; 
using System.Collections.Generic; 
using System.Linq; 
using System.Web; 
using System.Configuration; 

namespace BDZipper.Site 
{ 
    /// <summary> 
    /// This class maintains all session variables for us instead of handeling them 
    /// individually in the session. They are also strongly typed. 
    /// </summary> 
    public static class SessionManager 
    { 

     # region Private Constants 
     // Define string constant for each property. We use the constant to call the session variable 
     // easier not to make mistakes this way. 
     // I think for simplicity, we will use the same key string in the web.config AppSettings as 
     // we do for the session variable. This way we can use the same constant for both! 
     private const string startDirectory = "StartDirectory"; 
     private const string currentDirectory = "CurrentDirectory"; 

     # endregion 

     /// <summary> 
     /// The starting directory for the application 
     /// </summary> 
     public static string StartDirectory 
     { 
      get 
      { 
       return GetSessionValue(startDirectory, true); 
      } 
      //set 
      //{ 
      // HttpContext.Current.Session[startDirectory] = value; 
      //} 
     } 

     public static string CurrentDirectory 
     { 
      get 
      { 
       return GetSessionValue(currentDirectory, false); 
      } 
      set 
      { 
       HttpContext.Current.Session[currentDirectory] = value; 
      } 
     } 
     //TODO: Update to use any class or type 
     /// <summary> 
     /// Handles routine of getting values out of session and or AppSettings 
     /// </summary> 
     /// <param name="SessionVar"></param> 
     /// <param name="IsAppSetting"></param> 
     /// <returns></returns> 
     private static string GetSessionValue(string SessionVar, bool IsAppSetting) 
     { 
      if (null != HttpContext.Current.Session[SessionVar]) 
       return (string)HttpContext.Current.Session[SessionVar]; 
      else if (IsAppSetting) // Session null with appSetting value 
       return ConfigurationManager.AppSettings[SessionVar]; 
      else 
       return ""; 
     } 
    } 
}