Gestion de la session NHiernate dans Asp.Net
Auteur：Eve Cole
Date de mise à jour：2009-06-30 16:46:38
La session dans NHibernate semble être équivalente à une connexion à une base de données, à mon avis. Parce qu'il dispose également de méthodes Open/Close, je n'ai pas étudié le code source de NHibernate. Je me demande si cette compréhension est fausse ? J'ai beaucoup cherché sur la gestion de session sur Internet. La plupart d'entre eux sont OpenSession() lorsque j'ai besoin d'opérations de base de données, et CloseSession() après l'opération. C'est un peu similaire à lorsque nous avons commencé à apprendre ADO.NET, Open(. ) l'objet Connection, puis Close() une fois les données traitées. Mais cela présente un inconvénient, car les changements fréquents de Connection consomment des ressources système. Je me souviens de l'époque où je créais une interface de saisie de données auparavant, car cette interface de saisie comportait de nombreux éléments de données et de nombreuses DropDownLists devaient lire les données dans la base de données et les lier.
De cette façon, dans le Page_Load de la page, les méthodes des objets correspondants doivent être appelées une par une pour récupérer la liaison de données DropDownList de la base de données. Parce que les méthodes de nos objets utilisent des connexions indépendantes, elles ont toutes leurs propres connexions. propre ouverture et fermeture de la connexion. L’ouverture de cette page prend donc beaucoup de temps, ce qui est relativement lent. Plus tard, nous avons traité les données qui devaient être liées à DropDownList dans un DataSet, et lié le DataTable du DataSet à DropDownList. De cette façon, une seule ouverture/fermeture de connexion est requise. La page est beaucoup plus rapide.
Par conséquent, je pense que la méthode de gestion de session ci-dessus n'est pas très appropriée.
Plus tard, j'ai examiné sa gestion de session dans le projet open source Cuyahoga, et il a utilisé le modèle « session par demande ».
La compréhension littérale est qu'il crée une session pour chaque demande jusqu'à ce que la demande soit détruite, puis la session est fermée.
L'approche de Cuyahoga est un peu différente de la session par requête dans la mesure où il crée un objet CoreRepository pour chaque requête. CoreRepository est la classe de services de traitement de données requis par le système.
Ce qu'il a fait a été de créer d'abord HttpModule (NHSessionModule) pour créer des objets CoreRepository et détruire les objets CoreRepository, comme suit :
private void Context_BeginRequest (expéditeur de l'objet, EventArgs e)
{
// Créez le référentiel pour les objets Core et ajoutez-le au HttpContext actuel.
CoreRepository cr = new CoreRepository(true);
HttpContext.Current.Items.Add("CoreRepository", cr);
}
private void Context_EndRequest (expéditeur de l'objet, EventArgs e)
{
// Ferme la session NHibernate.
if (HttpContext.Current.Items["CoreRepository"] != null)
{
CoreRepository cr = (CoreRepository)HttpContext.Current.Items["CoreRepository"];
cr.CloseSession();
}
}
De cette façon, l'objet CoreRepository sera automatiquement créé à chaque fois qu'une demande est effectuée, CloseSession() peut être utilisé pour obtenir l'objet CoreRepository via HttpContext.Current.Items["CoreRepository"] dans le programme.
De cette façon, la session dans NHibernate est gérée sous une forme déguisée et le modèle « session par requête » est réalisé.
Explication détaillée : initialisez la session de Nhibernate en implémentant IHttpModule
Par rapport à la méthode ci-dessus, qui nécessite la création d'une session pour chaque opération, cette méthode devrait améliorer considérablement les performances et la vitesse.
Ensuite, j'ai pensé que chaque requête crée une session. Pouvons-nous également créer un pool de sessions comme le pool de connexions ?
De cette façon, au lieu de créer une session directement à chaque fois qu'une demande est faite, la session déjà créée est extraite de notre pool de sessions. N'est-ce pas plus efficace ? !
http://maplye.cnblogs.com/archive/2006/06/26/435683.html
