variable sesiones form .net nhibernate desktop-application

.net - variable - sesiones en windows form c#



¿Cuál es su estrategia de gestión de sesiones para NHibernate en aplicaciones de escritorio? (4)

Encuentro que es mucho más difícil administrar su sesión en una aplicación de escritorio, porque no puede aprovechar una bonificación tan clara como HttpContext. Entonces, ¿cómo gestiona la duración de su sesión para aprovechar la carga diferida pero sin tener una sesión abierta para toda la aplicación?


Como dijiste antes, no puedes usar el límite de HttpRequest, pero puedes entender qué es una "HttpRequest" en tu aplicación de escritorio.

Dejame explicar. Por lo general, su HttpRequest será un controlador para una acción y limitará su sesión a esa acción específica. Ahora, en su aplicación de escritorio, los "controladores" (eventos) pueden ser más pequeños, pero como dijo @Jon, una ventana puede representar fácilmente un límite: usted trabaja con las cosas allí, déjelos estar en su sesión.


Creo que se reduce al diseño de tus objetos. Debido a que la carga diferida puede imponerse en el nivel por objeto, puede aprovechar ese hecho cuando piensa en la administración de la sesión.

Por ejemplo, tengo un montón de objetos que son cargados de datos y de carga lenta, y tengo una vista de cuadrícula / resumen y una vista de detalles para ellos. En la vista de resumen de cuadrícula, no utilizo la versión de carga lenta del objeto. Utilizo un objeto sustituto para presentar esos datos, y ese objeto sustituto no tiene una carga lenta.

Por otro lado, una vez que un usuario selecciona ese registro para ver / editar e ingresa una vista de detalles con varias páginas del objeto, es cuando aplicamos la carga diferida al objeto específico. Los datos ahora se cargan de forma diferida dependiendo de qué detalles se visualizan solo a pedido. De esta forma, el alcance de mi sesión abierta para carga lenta solo dura mientras se usa la vista de detalles.


Tal vez podamos pensar en un patrón de comando configurado. Cada evento significativo alimentará y activará un Comando, y lo Ejecutará. La implementación básica de AbstractCommand.Execute () se encarga de inicializar la sesión, ajustar la transacción, llamar a la implementación concreta de SomeCommand._Execute () y cerrar todas las cosas.

De todos modos, esto está lejos de ser una persistencia agnóstica, como debería ser cuando he cargado mi objeto y yo (quiero) tratar solo con instancias simples (me refiero especialmente a lazy-load aquí).

¿De lo contrario es posible implementar algún tipo de comportamiento de apertura automática / cierre automático? Esto se debe lograr haciendo que la capa de persistencia sea más sensible a las necesidades de consultas de capas superiores, incluso en casos implícitos, como desencadenantes de carga lenta. En cuanto al cierre de la conexión, la capa de persistencia podría cerrarse después de un tiempo de espera dado (10 segundos?) De inactividad de DB. Lo sé, esto no es cortante. Pero realmente haría que las capas más altas persistan en agnóstico.

Gracias, Marcello