Discussion :

[mixaBaby]

Bonjour,

Je vais bientôt démarrer un projet et je me pose une question quand à l'utilisation de LINQ to SQL.
A savoir, cette technologie vous semble-t-elle adaptée à la conception d'un site ayant un fonctionnement similaire à celui d'un Forum (plusieurs utilisateurs simultanés, connexion concurrentes, etc...)

Si oui, comment gérer le ou les DataContext:
-Un global avec un Thread qui fait un SubmitChanges régulièrement (en gérant les conflits) ?
-Un par utilisateur ?
-... ?

Et si non, que me conseilleriez-vous d'autre ?

En vous remerciant par avance

[tomlev]

-Un global avec un Thread qui fait un SubmitChanges régulièrement (en gérant les conflits) ?

Surtout pas, tu vas te créer plein de problèmes inutilement...
S'il y a un problème sur le DataContext, ça va impacter tout le monde à la fois, et la gestion des conflits risque d'être un cauchemar

-Un par utilisateur ?

Le jour où tu auras 10000 utilisateurs simultanés, j'espère que ton serveur sera à la hauteur

En général, la bonne approche est de créer un DataContext par requête HTTP. Tu crées le DataContext quand tu en as besoin, et tu le Dispose dès que tu n'en n'as plus besoin. Et pas d'inquiétude pour le temps d'établissement de la connexion à la base, le pooling gère ça très bien

[meziantou]

Je pense que tomlev a raison sur l'utilisation des DataContext.
Je tiens quand même à ajouter que Linq to SQL n'est plus vraiment supporté par MS. Il est conseillé d'utiliser l'entity framework pour les nouveau projet.

[mixaBaby]

Merci pour vos réponses, cela m'a bien aidé
Bonne (fin de) soirée

[Jérôme Lambert]

J'aimerais rebondir sur la proposition de tomlev, si ça ne vous dérange pas, car je me suis aussi posé la question la première fois que j'ai voulu utiliser Linq to SQL pour un développement web :

En général, la bonne approche est de créer un DataContext par requête HTTP. Tu crées le DataContext quand tu en as besoin, et tu le Dispose dès que tu n'en n'as plus besoin. Et pas d'inquiétude pour le temps d'établissement de la connexion à la base, le pooling gère ça très bien

C'est aussi comme ça que j'ai commencé à utiliser Linq to SQL pour le développement web. Le but est très simple, une requête http arrive, on instancie le DataContext et dès qu'on en a besoin durant le traitement de la requête http, on l'utilise. Juste avant de renvoyer la réponse au client, on fait le dispose du datacontext pour être bien propre

Pensez-vous que ce soit la solution la plus propre ? Je me pose la question depuis un certain temps car il m'arrive trop souvent de me retrouver dans une portion de code, d'avoir besoin du datacontext pour une opération autre qu'un select (donc update, insert ou delete) sans me demander dans quel état est le datacontext. A-t-il des changes en attente ?

Un exemple de ce que j'essaye d'expliquer :

Code C# :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
public class Test
{
 public void Action1()
 {
  DataContext ctx = GetDataContext();
  ctx.Clients.InsertOnSubmit(new Client());
  Action2();
  ctx.SubmitChanges();
 }
 
 public void Action2()
 {
  DataContext ctx = GetDataContext();
  ctx.Products.InsertOnSubmit(new Product());
  ctx.SubmitChanges();
 }
}

Le code va fonctionner, j'en suis bien conscient mais est-ce que ça ne vous choque pas de voir la méthode "Action2" valider indirectement l'action de la méthode "Action1" ? L'exemple est très simple et ne laisse pas présager de problèmes par la suite. Mais dans un vrai gros projet où on récupère sans arrêt un peu partout le datacontext pour en obtenir un peu tout ce qu'on veut, qu'il y a des événements qui vont dans tous les sens, ne risque-t-on pas de se retrouver dans des situations bien plus dangereuses ? Et je ne parle même pas d'utilisation des transactions.

Depuis qeulques temps, j'essaye une autre façon de faire : je consacre une librairie pour tous mes accès db. A chaque action avec la db correspond une méthode et chaque méthode instancie son propre datacontext. A la sortie de la méthode, dispose du datacontext. Cette technique a un point faible, si on retourne des objets venant du datacontext, il ne seront plus tracké et on ne pourra pas utiliser non plus les propriétés différées étant donné que le datacontext aura été disposé. Vous me suivez ? (ce que j'utilise comme alternative, c'est que mes méthode ne renvoit pas des objets du datacontext car ceux sont convertit en un autre type à chaque fois.

Qu'en pensez-vous ?

[tomlev]

Je vois le problème, mais je sais pas trop comment le contourner

A priori une solution serait d'appeler SubmitChanges à un seul endroit, de façon à le faire une seule fois par requête. Mais y a sans doute des cas où on peut avoir besoin de le faire plus tôt...