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

Question

Me resulta mucho más difícil gestionar tu sesión en una aplicación de escritorio, porque no puedes aprovechar un vínculo tan claro 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?

Answer 1

Creo que todo se reduce al diseño de tus objetos.Debido a que la carga diferida se puede aplicar a nivel por objeto, puedes aprovechar ese hecho cuando piensas en la gestión de sesiones.

Por ejemplo, tengo un montón de objetos que son ricos en datos y se cargan de forma diferida, y tengo una vista de cuadrícula/resumen y una vista de detalles para ellos.En la vista de resumen de cuadrícula, no uso la versión del objeto con carga diferida.Utilizo un objeto sustituto para presentar esos datos, y ese objeto sustituto no se carga de forma diferida.

Por otro lado, una vez que un usuario selecciona ese registro para verlo o editarlo y usted ingresa a una vista de detalles de 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 ven solo bajo demanda.De esa manera, el alcance de mi sesión abierta para carga diferida solo dura mientras se utiliza la vista de detalles.

Answer 2

Ayende ha escrito recientemente un gran artículo sobre el tema en MSDN.

Answer 3

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:Trabajas con las cosas allí, déjalas estar en tu sesión.

Answer 4

Quizás 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() está a cargo de inicializar la sesión, envolver la transacción, llamar a la implementación concreta de SomeCommand._Execute() y cerrar todo.

De todos modos, esto está lejos de ser independiente de la persistencia, como debería serlo cuando he cargado mi objeto y (quiero) tratar solo con instancias simples (aquí me refiero especialmente a la carga diferida).

¿Es posible implementar algún tipo de comportamiento de apertura/cierre automático?Esto debe lograrse haciendo que la capa de persistencia sea sensible a las necesidades de consultas de capas superiores, incluso en casos implícitos como los activadores de carga diferida.En cuanto al cierre de la conexión, la capa de persistencia podría cerrarse después de un tiempo de espera determinado (¿10 segundos?) de inactividad de la base de datos.Lo sé, esto no es agudo.Pero realmente haría que la persistencia de las capas superiores fuera independiente.

Gracias Marcello