Discussion :

[olysmar2]

Bonjour,

Je suis entrain de construire une application et je m'interroge sur la gestion de la base de données.
Je m'explique:
J'ai construit une DAL pour l'accés à la base de données.
Cette Dal une fois intialisé ne traite qu'une connexion à la fois et qu'une seul transaction à la fois.

A l'initailisation de la session de l'utilisateur, j'initialise une instance de cette DAL que j'utilise tout au long de la session.

Cela fonctionne bien si mon utilisateur de session ne peut faire qu'un seul accés serveur au même moment.

Mais je crois qu'il est possible que mon utilisateur face plusieurs accés au serveur dans un même temps:
Je m'explique: Si mon utilisateur lance un traitement via callback sur le serveur et que pendant ce callback, il lance un autre traitement via un autre callback, alors je suppose que j'aurais deux traitements parralèle sur mon serveur pour la même session? Mon hypothèse est-elle juste ?

Du coup, ma DAL ne fonctionnera car j'aurais deux traitements qui rentrerons en conflit sur la même instance de DAL ?

Merci pour vos lumières
Sylo

[M_Makia]

Bonjour olysmar2,

Du coup, ma DAL ne fonctionnera car j'aurais deux traitements qui rentrerons en conflit sur la même instance de DAL ?

Oui effectivement ça peut te poser des problèmes !!!

La session est pratique mais trop persistante pour l'utilisation d'une DAL, tu risques d'avoir des effet de bord si tu continues sur cette voie ( ralentissements, bug, crash, consommation mémoire importante voir fuite mémoire ... ).

je te conseille de stocker ta DAL juste le temps d'une requête Http avec l'objet => HttpContext.Current.Items["MyKey"]

Cet objet est assez méconnu des développeurs, c'est simplement un dictionnaire clé/valeur comme une session mais l'objet est stocké en mémoire juste le temps d'une requête.

[DotNetMatt]

Utiliser un Singleton pour une DAL est une très mauvaise idée pour une application ASP.NET, car dans l'absolu un seul utilisateur pourra être servi, les autres seront mis en attente.

De plus, les connexions doivent être ouvertes et fermées le plus rapidement possible, tout ceci étant géré derrière par le regroupement de connexions (connection pooling), donc à priori il n'y a également aucun intérêt à stocker une instance de la DAL, sauf si tu as une architecture spécifique qui le nécessite absolument.

Enfin, si on reste sur les principes basiques d'architecture, la DAL ne devrait être appelée que par la couche Business, éventuellement par d'autres couches intermédiaires, mais certainement pas par la couche UI.

[olysmar2]

Pour répondre à DotNetMatt, Ma Dal ouvre et ferme les connexion à chaque requète, a moins que je ne l'ouvre manuellement dans la dal, et dans ce cas là, c'est à mois de veiller à la fermer (particulièrement dans le cadre d'une transaction)
Par contre, je ne comprend pas pourquoi tu me dis qu'un seul utilisateur pourra être servi? Chaque utilisateur dispose d'une instance de sa DAL avec sa propre connexion, donc je ne vois pas le problème... C'est un peu comme si mes users ouvrait et fermait la connexion via un sqlconnection sauf que l'ADO est déporté dans la DAL... Si une connexion reste ouverte, c'est que j'ai mal gérer mes objets...
Enfin, pour les principes de bases de l'architecture, je comprend bien ce que tu me dis, mais ce n'est pas mon soucis majeur pour l'application que je développe...
Merci tout de même pour toutes ces informations

En tous les cas, ce que me propose Makia semble correspondre à mon attente... Je vais creuser de ce coté là

Merci beaucoup
Sylo

[olysmar2]

La solution de Makia semble bien fonctionner.
Merci beaucoup
Sylo