Uso de la sesión de ASP.NET para la gestión de por vida (Unity)

Question

Estoy considerando utilizar Unity para administrar la vida útil de una instancia de clase de usuario personalizada. Planeo extender el LifetimeManager con un administrador de sesiones ASP.NET personalizado. Lo que quiero hacer es almacenar y recuperar el objeto de usuario actualmente conectado de mis clases personalizadas, y hacer que Unity obtenga la instancia de Usuario del objeto de sesión en ASP.NET, o (cuando está en un proyecto de Win32) recuperarlo estáticamente o del hilo actual.

Hasta ahora, mi mejor solución es crear una instancia estática de mi contenedor de Unity al inicio y usar el método Resolver para obtener mi objeto de usuario de cada una de mis clases. Sin embargo, esto parece crear una dependencia en el contenedor de la unidad en mis otras clases. ¿Cuál es la forma más "Unitaria" de lograr este objetivo? Me gustaría poder leer/reemplazar la instancia de usuario actual de cualquier clase.

Answer 1

Creo que necesita dos servicios que expone a través de la unidad (o un servicio que realiza ambas acciones).

En lugar de almacenar el objeto de usuario, almacene una implementación de interfaz que expone un método/propiedad que obtendrá el objeto de usuario para usted. En el caso ASP.NET, recuperas al usuario de la sesión. En la solución WinForm (o lo que sea), puede obtenerlo desde el hilo de ejecución.

También tendría un método/propiedad de conjunto, que usaría para configurar el usuario.

Answer 2

Parece que realmente necesita un patrón de registro, no Unity.

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

Answer 3

Por qué no utilizar el objeto de caché en lugar ... entonces se puede usar tanto de la victoria y de la tela. De esta manera:

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 trabajará tanto en la victoria y la web

Answer 4

Mis disculpas si esto no es del todo bien, pero ...

La unidad es una plataforma de juego dev, por lo tanto, suponga que está construyendo una aplicación o juego en 3D con el que pretende hacer algo interesante (por ejemplo, hacer que el jugador/multijugador progrese usando el servidor).

Por qué no tener cada usuario de inicio de sesión, entonces puede utilizar las clases MembershipProvider y Formsauthentication para obtener acceso a la identificación/nombre de los usuarios.

En su servidor, simplemente vincula toda la información a la del usuario, lo que le permite recuperar fácilmente datos simples (ajax/solicitud http normal) relevantes para la situación/solicitud del usuario.

No lo sé con certeza, pero creo que la unidad es algo que despliega el lado del cliente, por lo tanto, no es necesario realizar ninguna integración en el servidor.

Simplemente solicite lo que necesita y trátelo en el lado del cliente.

De esta manera, se adhiere al patrón de diseño de n niveles clásico que le permite separar su lógica de su almacenamiento de datos y ui.

Espero que esto ayude ...

Answer 5

se obtendría el mejor partido con la unidad cuando se utiliza con ASP.Net MVC en lugar del proyecto de ASP.Net simple y llano. ASP.Net MVC le permite usar un contenedor como Unity para administrar los objetos del usuario, controladores, modelos, etc. Si es posible, use MVC en lugar de ASP.formularios web netos para sus proyectos.

Si entiendo su pregunta correctamente, querrá usar Unity para mantener el tiempo de vida del objeto por sesión. Debe implementar un SessionLifetimeManager que extienda LifetimeManager. El código es bastante simple y va a lo largo de estas líneas:

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); 
    } 
} 

También podría escribir uno similar para la administración de la duración PerWebRequest.

Answer 6

Tal vez estoy pensando demasiado en esto, pero creo que deberías usar AoP junto con IoC. Es realmente una pareja hermosa. Esencialmente, lo que haría es secuestrar el constructor de las clases que está resolviendo, de lo contrario, crear un aspecto. A continuación, puede inyectar al usuario en la clase al ingresar al constructor, pero lo que sea que resuelva la clase no tiene que proporcionar explícitamente al usuario, por lo que no se puede emparejar con Unity.

PostSharp es un excelente marco de AoP en mi humilde opinión.

Ahora, al final, su aplicación dependerá del marco AoP, pero una aplicación completamente desacoplada puede ser poco realista según su entorno. Puede que se sorprenda de lo útil que puede ser la combinación de AoP e IoC.

Answer 7

Si por "un administrador de sesión ASP.NET personalizado" está hablando de una sesión de NHibernate o un Data/ObjectContext, parece que lo que necesita es un IUserRepository inyectado en el constructor o el conjunto de propiedades desde el que puede recuperar el objeto Usuario. La implementación de IUserRepository podría ser cualquier cosa, desde el acceso a la base de datos hasta un caché back-end, etc. Si está usando .Resolve() en el contenedor directamente, está siguiendo el patrón Service Locator y no usa Unity correctamente para todo lo que puede proporcionar.

Puede usar Ravi's answer para administrar la vida útil del repositorio.