Использование сеанса ASP.NET для управления жизненным циклом (Unity)

Question

Я рассматриваю возможность использования Unity для управления временем жизни пользовательского экземпляра пользовательского класса. Я планирую расширить LifetimeManager с помощью специального менеджера сеансов ASP.NET. Я хочу, чтобы иметь возможность хранить и извлекать текущий пользовательский объект из моих пользовательских классов, а Unity - получить экземпляр пользователя из объекта сеанса в ASP.NET или (когда в проекте Win32) получить его статически или от текущей нити.

До сих пор моим лучшим решением было создать статический экземпляр контейнера Unity при запуске и использовать метод Resolve для получения объекта User от каждого из моих классов. Однако, похоже, это создает зависимость от контейнера единства в моих других классах. Чем больше «Единство» способ достижения этой цели? Я хотел бы иметь возможность читать/заменять текущий экземпляр пользователя из любого класса.

Answer 1

Я бы подумал, что вам нужны две службы, которые вы открываете через единство (или одну службу, которая выполняет оба действия).

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

У вас также есть метод/свойство set, который вы использовали бы для установки пользователя.

Answer 2

Звучит как на самом деле вам нужен реестр, а не Единство.

http://martinfowler.com/eaaCatalog/registry.html

Answer 3

Почему бы не использовать объект кэша вместо ... то вы можете использовать его как от победы и сети. Как это:

IUnityContainer container= HttpRuntime.Cache.Get("Unity") as IUnityContainer; 

    if (container == null) 
    { 
     container= // init container 

     HttpRuntime.Cache.Add("Unity", 
      container, 
      null, 
      Cache.NoAbsoluteExpiration, 
      Cache.NoSlidingExpiration, 
      CacheItemPriority.NotRemovable, 
      null); 
    } 

    // return container or something 

HttpRuntime.Cache будет работать как в выигрыше и веб

Answer 4

Мои извинения, если это не совсем верно, но ...

Unity является разработчиком игр платформы, поэтому я предположим, что вы создаете 3D-приложение или игру, в которой вы намерены делать что-то классное (например, сделать его многопользовательским/отслеживать прогресс пользователей с использованием сервера).

Почему бы не войти в каждый пользователь, тогда вы можете использовать классы MembershipProvider и Formsauthentication, чтобы получить доступ к идентификатору/имени пользователя.

На вашем сервере вы просто связываете всю информацию с информацией для пользователя, которая позволяет легко отбрасывать данные (простые данные ajax/normal http), относящиеся к ситуации/запросу пользователей.

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

Просто спросите, что вам нужно, и обработайте его на стороне клиента.

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

Надеется, что это помогает ...

Answer 5

Вы бы получить лучший удар с Unity, когда используются с ASP.Net MVC, а не обычным старым проектом ASP.Net. ASP.Net MVC позволяет использовать контейнер типа Unity для управления объектами пользователя, контроллерами, моделями и т. Д. Если возможно, используйте MVC, а не ASP.сетевые формы для ваших проектов.

Если я правильно понял ваш вопрос, вы бы хотели использовать Unity для поддержания времени жизни объекта за сеанс. Вам необходимо реализовать SessionLifetimeManager, который расширяет LifetimeManager. Код очень прост и идет вдоль этих линий:

public class SessionLifetimeManager : LifetimeManager 
{ 
    private string _key = Guid.NewGuid().ToString(); 

    public override object GetValue() 
    { 
      return HttpContext.Current.Session[_key]; 
    } 

    public override void SetValue(object value) 
    { 
      HttpContext.Current.Session[_key] = value; 
    } 

    public override void RemoveValue() 
    { 
      HttpContext.Current.Session.Remove(_key); 
    } 
} 

Вы также можете написать подобное одно для PerWebRequest управления жизненным циклом.

Answer 6

Возможно, я передумал, но думаю, вы должны использовать AoP вместе с IoC. Это действительно красивое спаривание. По сути дела, что я хотел бы сделать, это захватить конструктор классов, которые вы разрешаете, иначе называете создание аспект. Затем вы можете ввести пользователя в класс при входе в конструктор, но все, что разрешает класс, явно не должно предоставлять пользователю, тем самым предотвращая спаривание с самим Unity.

PostSharp - отличная инфраструктура AoP IMHO.

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

Answer 7

Если «пользовательский менеджер сеансов ASP.NET» вы говорите о сеансе NHibernate или Data/ObjectContext, это похоже на то, что вам нужно, это IUserRepository, введенный либо в конструктор, либо с помощью средства настройки свойств, из которого вы можете получить объект User. Реализация IUserRepository может быть чем угодно: от доступа к базе данных до бэкэнд-кеша и т. Д. Если вы используете Rewolve() непосредственно в контейнере, вы следуете шаблону Service Locator и не используете Unity для всего, что он может предоставить.

Затем вы можете использовать Ravi's answer для управления временем жизни репозитория.