Discussion :

[Invité]

Bonjour, je réalise dans le cadre d'un stage, une application de suivi de facture...Pour cela, je dois créer différents classes ( Classe Personne, client; facture...). La base de donnée utilisée est Sql Server 2005. L'utilisation du logiciel sera mono-utilisateur. Je sais pas exactement quoi choisir. Je cherche surtout la simplicité...

Qu'est ce que je peux choisir ?

[anthyme]

LinqToSQL simple, efficace (particulierement en monoutilisateur) avec de tres tres bons outils dans VS

ses limitations : contexte moyen en multi utilisateur et sql server seulement donc pour toi c nickel

[tomlev]

Ah bon, pourquoi c'est moyen en multi-utilisateur ? SQL Server supporte très bien les utilisateurs multiples, et le mapping objet ne devrait pas changer ça il me semble... ou alors quelque chose m'échappe ?

[anthyme]

a vrai dire c'est au niveau du context de persistance qui propose pas mal de truc sympa comme du cache où il sait détécter ce qui à été modifié dans SON context.

Le probleme c'est que comme il est pas thread safe tu peux pas lui demander plusieurs requetes a la fois ce qui dans 99% des cas en production t'oblige donc a créer plusieurs DataContext et donc perdre pas mal d avantage du context.

J'avais vu quelqu'un faire des context sur plusieur scope comme un général a l'appli pour les requetes en lecture et un autre pour celle en ecriture mais bon au final c'etait pas parfait... Bref je pense qu'il va falloir attendre linq to entities pour avoir un contexte de persistance digne d hibernate et co.

PS: JE ne remetait pas en cause SQL server qui est une tres bonne base de données

[tomlev]

PS: JE ne remetait pas en cause SQL server qui est une tres bonne base de données

Oh ben tu sais, tu peux remettre en cause tant que tu veux... je préfère Oracle de toutes façons

[SaumonAgile]

Le probleme c'est que comme il est pas thread safe tu peux pas lui demander plusieurs requetes a la fois ce qui dans 99% des cas en production t'oblige donc a créer plusieurs DataContext et donc perdre pas mal d avantage du context.

Il suffit simplement de déléguer les accès à un thread dédiés qui manipule le datacontext.
Ta couche métier n'a pas besoin/envie de savoir s'il y a ou non un datacontext en dessous, le thread tourne de toute façon dans ta couche data access.
Sachant en plus que dans le cas d'une architecture d'entreprise standard intercalant des couches de services, tu ne dois jamais passer de contexte entre les tiers sous peine de perdre toute forme de découplage.

[anthyme]

un seul datacontext dans un seul thread = 1 seul requête a la base de donnée a la fois .... bonjour les les performances

Si y a 100 personne qui arrive en même temps il va falloir attendre que les 99 première ai fini leur requête pour avoir le 100 eme résultat ? c'est pas génial une base de donnée c fait pour qu'on puisse lui lancer plusieurs requête a la fois mais ce datacontext non donc voila dans une majorité de cas c useless ...