¿Puedo usar la variable de sesión de ASP.NET [] en una DLL externa

Question

Tengo dos proyectos, el proyecto DLL que tiene todas mis cosas de lógica y acceso a datos, y el proyecto ASP.NET que hace mis formularios, etc.

Estoy un poco confundido. Pensé que si agregaba la referencia del espacio de nombres System.Web al proyecto DLL, podría hacer referencia a la información del estado de la sesión de la página ASP.NET.

Podría usar cada página para obtener la información de la sesión y pasarla a la DLL para el procesamiento, pero me encantaría poder procesar cosas directamente desde la (s) clase (s) de la DLL.

¿Es esto posible?

He manipulado el espacio de nombres System.Web y parece que puedo obtener una referencia a la variable Session.

Gracias a todos.

Jon

Answer 1

Debería poder usar HttpContext.Current.Session

Editar

Aunque sí, estoy de acuerdo en que no debe acoplar estrechamente sus ensamblados de Business Logic DAL o etc. a la sesión ASP.Net. Hay muchos casos válidos para acceder al contexto HTTP fuera de un proyecto web.

Web Controls es probablemente uno de los mejores ejemplos, módulos http reutilizables, etc., etc.

Ahora, una opción si desea que su DLL extraiga el material de la sesión es abstraer la sesión. Por lo tanto, podría definir una interfaz como IStorage, que su biblioteca sabrá cómo usar. Entonces puede tener una clase SessionStorage o MemoryStorage y usar IoC para inyectar la clase apropiada en sus clases de biblioteca. Esto le da la libertad de codificarlo como desea que se codifique sin vincular su código a Session. Ah, y otro beneficio si se hace correctamente puede usarse para no vincular su código a la sesión en la web tampoco.

Answer 2

Mientras la Asamblea se cargue en el alcance de la Sesión, tendrá acceso.

Aunque este tipo de acoplamiento apretado no se recomienda realmente.

Answer 3

Siempre puede usar HttpContext.Current.Session en su DLL, pero esto se considera una mala práctica. Un mejor enfoque sería pasar los valores almacenados en el diccionario de sesión a su DLL en lugar de hacer referencia a la sesión. Otro beneficio que obtendrá es que el código en su DLL no estará acoplado al tiempo de ejecución ASP.NET, lo que significa que será más fácil de probar.

Answer 4

Como dijeron los demás, siempre puedes usar HttpContext.Current.Session en tu DLL, supongo que es tu BAL, pero debes tener mucho cuidado. ¿Qué sucede si su servicio de Windows o alguna otra aplicación que no tiene un HTTPContext consume su DLL? Siempre que he hecho esto, siempre ha estado en un método de obtención de propiedades donde envuelvo el intento de acceder a HttpContext.Current.Session en un bloque try catch y, si algo sale mal, vuelvo a extraer los datos necesarios de la base de datos.

Answer 5

No use HttpContext.Current.Session ya que su dll no se ejecutará siempre con la aplicación web. Puede ejecutarse con cualquier otra aplicación como Windows, Console itc.

Es mejor usar un Método que acepte realmente un parámetro, que vendrá desde el Valor de sesión, si está usando la Aplicación ASP.Net, de lo contrario no habrá ninguna dependencia de la aplicación. Si su proyecto dll ya está desarrollado y está intentando modificar la lógica comercial existente, entonces no, no modifique su método actual, utilice un método de sobrecarga.