Quelle est votre stratégie de gestion de session pour NHibernate dans les applications de bureau?

Question

Je trouve qu'il est beaucoup plus difficile de gérer votre session dans une application de bureau, car vous ne pouvez pas tirer parti d'un lien aussi clair que celui de HttpContext. Alors, comment gérez-vous la durée de votre session pour tirer parti d'un chargement paresseux sans avoir à ouvrir une session pour l'ensemble de l'application?

Answer 1

Je pense que cela se résume à la conception de vos objets. Le chargement paresseux pouvant être appliqué au niveau de chaque objet, vous pouvez en tirer parti lorsque vous réfléchissez à la gestion de session.

Par exemple, j'ai un tas d'objets riches en données et chargés en paresseux, et j'ai une vue grille / résumé et une vue détaillée pour eux. Dans la vue récapitulative de la grille, je n'utilise pas la version de l'objet chargée paresseux. J'utilise un objet de substitution pour présenter ces données, et cet objet de substitution n'est pas chargé paresseux.

D'un autre côté, une fois qu'un utilisateur sélectionne cet enregistrement pour affichage / édition et que vous entrez une vue détaillée paginée de l'objet, nous appliquons alors un chargement différé à cet objet. Les données sont maintenant chargées paresseusement en fonction des détails visualisés uniquement à la demande. De cette façon, la portée de ma session ouverte pour le chargement paresseux ne dure que tant que la vue Détails est utilisée.

Answer 2

Ayende a récemment écrit un excellent article sur le sujet dans MSDN . .

Answer 3

Comme vous l'avez dit précédemment, vous ne pouvez pas utiliser la limite de HttpRequest, mais vous pouvez comprendre ce qu'est un "HttpRequest". dans votre application de bureau.

Laisse-moi t'expliquer. Habituellement, votre requête HttpRequest sera un contrôleur pour une action et vous limiterez votre session à cette action spécifique. Maintenant, dans votre application de bureau, les "contrôleurs" (événements) peut être plus petit, mais comme l'a dit @Jon, une fenêtre peut facilement représenter une limite: vous travaillez avec les éléments présents, laissez-les être sur votre session.

Answer 4

Peut-être pouvons-nous penser à un modèle de commande mis en place. Chaque événement significatif alimentera et déclenchera une commande, puis l'exécutera. L’implémentation de base AbstractCommand.Execute () est chargée d’initialiser la session, d’envelopper la transaction, d’appeler l’implémentation concrète SomeCommand._Execute () et de fermer tous les éléments.

Quoi qu’il en soit, c’est loin d’être agnostique en termes de persistance, comme cela devrait être le cas lorsque j’ai chargé mon objet et que je (veux) traiter uniquement les instances simples (je parle spécialement de paresseux-load ici).

Est-il possible par ailleurs d'implémenter une sorte de comportement d'ouverture / fermeture automatique? Cela devrait être accompli en rendant la couche de persistance sensible aux besoins de requêtes des couches supérieures, même dans les cas implicites tels que les déclencheurs de chargement paresseux. En ce qui concerne la fermeture de la connexion, la couche de persistance peut se fermer après un délai d'inactivité donné (10 secondes?) D'inactivité de la base de données. Je sais, ce n'est pas net. Mais cela rendrait vraiment les couches supérieures agnostiques.

Merci, Marcello