En supposant que vous êtes déjà à l'aise avec XML et la configuration NHibernate lui-même, il y a un objet que vous avez besoin de faire un singleton, qui est, l'API ISessionFactory . La raison pour laquelle ceci devrait être fait en singleton est que la configuration complète en ce qui concerne votre connexion, ainsi que tous les mappages d'entités sont chargés en mémoire afin que NHibernate sache comment et où persister dans la banque de données sous-jacente. Par conséquent, l'API ISessionFactory est très coûteuse à instancier. En ce qui concerne les sessions, il y a deux aspects à prendre en compte, que vous souhaitiez une session sans état ou avec une session statefull. Ce choix vous appartient entièrement, mais connaissez la différence.
L'API ISession conserve une trace de chaque modification sur une entité attachée. Une entité attachée est une entité qui a été chargée à partir du magasin de données sous-jacent en utilisant l'un des moyens possibles fournis par NHibernate, ou, d'autre part, une entité transitoire qui vient d'être instanciée et que vous avez attachée à la session. Garder une telle session statefull en vie pour toolong peut provoquer une perte de données comme le sera le moment où cette API fuit en mémoire. Une fois qu'une fuite se produit, toute la trace des modifications est saccagée et la session ne peut plus être utilisée. L'API ISession doit toujours être utilisée avec l'API ITransaction. Le ITransaction est probablement identique à un Begin Transaction directement dans SQL (TSQL, PL/SQL et autres). Chaque fois que vous avez besoin de persister dans la base de données, vous devez le faire en utilisant une transaction afin d'empêcher les erreurs d'annuler les modifications ou quoi que ce soit. L'API ISession doit être instanciée au début d'une unité de travail. Une seule instance API ISession peut être requise pour gérer plusieurs formulaires à la fois. Cela dit, faire d'une instance API ISession un singleton est une très, très mauvaise idée, pour la raison de la gestion de la mémoire, pour laquelle le ISession garde une trace de toutes les modifications survenues à une entité attachée. Si vous gardez l'API ISession active trop longtemps, elle utilisera de plus en plus de mémoire, ce qui entraînera des fuites de mémoire et une corbeille de la session.
L'API IStatelessSession fait ce qu'elle dit être. Étant apatride, il ne garde aucune trace des modifications apportées à un objet joint. Donc, vous devrez savoir manuellement ce qui doit être fait comme une action contre la base de données pour cette entité que vous avez l'intention de persister, disons. Le IStatelessSession utilise également l'API ITransaction à travers laquelle il peut gérer l'intégrité des données. Ces deux doivent toujours être utilisés les uns avec les autres lors de la connexion au magasin de données. Le IStatelessSession est souvent utilisé sous la forme de créer-comme-nécessaire, car il n'a pas d'autre utilisation que de «parler» avec le magasin de données. Cette API est principalement utilisée, je crois, dans les applications Web où les règles sans état sont les plus courantes.
Une fois que vous avez choisi ce qui correspond le mieux à vos exigences entre les API ISession et IStatelessSesion, vous êtes prêt à partir.