c# - studio - unity tutorial

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

Question

Estoy considerando usar Unity para administrar la vida útil de una instancia de clase de usuario personalizada. Estoy planeando extender el LifetimeManager con un administrador de sesión ASP.NET personalizado. Lo que quiero poder hacer es almacenar y recuperar el objeto de usuario registrado actualmente 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 desde el hilo actual.

Hasta ahora mi mejor solución es crear una instancia estática de mi contenedor de Unity en el inicio y usar el método Resolver para obtener mi objeto 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 esta meta? 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 exponga un método / propiedad que obtendrá el objeto de usuario por usted. En el caso de ASP.NET, recupera al usuario de la sesión. En la solución de WinForm (o lo que sea), puede obtenerla desde el subproceso de ejecución.

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

Answer 2

Mis disculpas si esto no está bien, pero ...

Unity es una plataforma de desarrollo de juegos, por lo tanto, asumo que estás construyendo una aplicación o juego en 3D con el que pretendes hacer algo genial (por ejemplo, haz que los usuarios de multijugador / seguimiento progresen utilizando el servidor).

¿Por qué no hacer que cada usuario inicie sesión? Entonces, puede usar las clases MembershipProvider y Formsauthentication para obtener acceso a la identificación / nombre de los usuarios.

En su servidor, simplemente vincule toda la información a la del usuario, lo que le permite retirar fácilmente los datos relevantes (solicitud simple ajax / http http) correspondientes a la situación / solicitud del usuario.

No lo sé con seguridad, pero creo que la unidad es algo que implementa el lado del cliente, por lo que no es necesario realizar una integración en el servidor.

Simplemente solicite lo que necesita y procéselo en el lado del cliente.

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

Espero que esto ayude ...

Answer 3

Obtendría el mejor resultado con Unity cuando se usara con ASP.Net MVC en lugar del simple proyecto ASP.Net. ASP.Net MVC le permite usar un contenedor como Unity para administrar los objetos de usuario, controladores, modelos, etc. Si es posible, use MVC en lugar de los formularios web de ASP.net para sus proyectos.

Si entiendo su pregunta correctamente, desearía usar Unity para mantener la vida útil del objeto por sesión. Debe implementar un SessionLifetimeManager que amplíe LifetimeManager. El código es bastante simple y sigue 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 puede escribir uno similar para la administración de por vida de PerWebRequest.

Answer 4

Parece que en realidad necesitas un patrón de registro, no Unity.

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

Answer 5

Por qué no usar el objeto de caché en su lugar ... entonces puedes usarlo tanto desde win como desde web. Me gusta esto:

    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 funcionará tanto en win como en web

Answer 6

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

Luego puedes usar la respuesta de Ravi para administrar la vida útil del repositorio.

Answer 7

Tal vez estoy pensando demasiado en esto, pero creo que deberías usar AoP junto con IoC. Es realmente una hermosa pareja. Esencialmente, lo que haría es secuestrar al constructor de las clases que está resolviendo, lo que también se denomina crear un aspecto. Luego, podría inyectar al usuario en la clase al ingresar al constructor, pero lo que resuelva la clase no tiene que proporcionar explícitamente al usuario, lo que evita que se vincule con Unity.

PostSharp es un excelente marco AoP IMHO.

Ahora, al final, su aplicación dependerá del marco de AoP, pero una aplicación completamente desacoplada puede no ser realista dependiendo de su entorno. Es posible que se sorprenda de lo útil que puede ser la combinación de AoP y IoC.