Как получить доступ к значениям сеанса из слоев под слоем веб-приложения - PullRequest
1 голос
/ 24 апреля 2010

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

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

Ответы [ 3 ]

3 голосов
/ 24 апреля 2010

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

Таким образом, вместо того, чтобы передавать объект Session непосредственно им, вы должны заключить нужные методы доступа к информации в класс репозитория. Ваш бизнес-уровень может использовать класс хранилища в качестве источника данных (например, вызов GetUser() для него), а хранилище для вашего веб-приложения может использовать сеанс для получения запрошенной информации (возврат _session.User.Identity).

При переносе на winforms просто реализуйте интерфейс репозитория с новым классом, ориентированным на winform (т. Е. GetUser() возвращает версию пользователя для Windows).

1 голос
/ 24 апреля 2010

Теоретически люди скажут вам, что это плохая деловая практика. На практике нам просто нужны были данные с уровня сеанса, постоянно доступные на бизнес-уровнях. : - (

Мы закончили тем, что объединили разные механизмы хранения под небольшим интерфейсом.

public interface ISessionStorage 
{
   SomeSessionData Data {get;set;}
   ...
   .. and most of the data we need stored at "session" level
    }
 //and a singleton to access it
    public static ISessionStorage ISessionStorage;

этот интерфейс доступен практически в любом месте нашего кода.

Тогда у нас есть как Session, так и / или одноэлементная реализация

 public WebSessionStorage
{
   public SomeSessionData Data 
  {
       get { return HttpContext.Current.Session["somekey"] as SomeSessionData;}
      set { HttpContext.Current.Session["somekey"] = value;}
  }

public WebFormsSessionStorage
{
   private static SomeSessionData  _SomeSessionData; //this was before automatic get;set;
   public SomeSessionData 
   {
       get{ return _SomeSessionData;}
       set{ _SomeSessionData=value; }
}

}

При запуске приложения, сайт будет делать

 Framework.Storage.SessionStorage = new WebSessionStorage(); 

в Global.asax, и FormsApp сделает

 Framework.Storage.SessionStorage = new WebFormsSessionStorage(); 
0 голосов
/ 24 апреля 2010

Я полностью согласен с Womp - добавьте данные из внешнего интерфейса в нижние уровни.

Если вы хотите сделать чит на полпути (но не слишком чит), то вы можете создать очень маленькую сборку с парой классов POCO для хранения всего этого информацию, которой вы хотите поделиться на всех ваших уровнях (текущее имя пользователя, время входа и т. д.) и просто передать этот объект из внешнего интерфейса в уровни biz / data. Теперь, если вы сделаете это, вы ДОЛЖНЫ избежать соблазна превратить эту сборку POCO в общую сборку утилит - она ​​ДОЛЖНА остаться маленькой, или у вас БУДУТ проблемы в будущем (поверьте мне или изучите трудный путь или попросите кого-нибудь еще уточнить об этом один). Однако, если у вас есть эта сборка POCO, внедрение этих данных через различные уровни становится очень простым, и, поскольку это POCO, она очень хорошо сериализуется и прекрасно работает с веб-сервисами, WCF и т. Д.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...