2009-03-31 4 views
3

Je vois ce modèle partout, mais Linq to SQL ne l'implémente pas. Si les objets Session/Unité de travail sont légers (peuvent être créés et détruits sans pénalité de performance) et que le regroupement de connexions maintient les connexions de base de données actives, pourquoi et quand ai-je besoin du modèle session par requête?Quand devrais-je utiliser le modèle session par requête

Répondre

3

Je crois que l'idée de session-per-request est plus au sujet de quand vous ouvrez et fermez la session, pas au sujet d'obtenir des améliorations de performance.

L'idée est que

  1. Ouverture d'une session commencera une transaction avant que votre code est toujours appelé
  2. Votre logique métier et votre cadre a un accès complet à la base de données jusqu'à ce que la dernière possible moment
  3. Votre transaction est engagée pour vous, au lieu de devoir le faire à chaque fois

L'idée de # 2 est importante pour que vous puissiez mélanger les frameworks web et le chargement paresseux des données; Si une méthode getter est appelée lors du rendu de vos données après l'exécution de votre code et que vous avez fermé la session, vous ne pouvez pas charger paresseusement le résultat de ce getter.

0

C'est en fait une bonne question que presque tous les tutoriels semblent éviter.

Si vous n'utilisez pas le chargement paresseux, vous n'en avez pas besoin.

Questions connexes