Discussion :

[sheitancrew]

Bonjour,

( C#, framework 3.5, VS 2008)

J'ai à faire une présentation dans le cadre de mes études sur Linq to SQL, sachant que je travaille actuellement avec des DataSets typés.

Seulement, malgré mes longues recherches j'ai vraiment du mal à dégager un intéret à cette technologie, ses points forts par rapport aux Datasets...

J'ai cru comprendre que l'atout majeur de LINQ était de garder une même requete, un même "Fill", adaptable à plusieurs sources de données.
Donc dans l'hypothèse ou ma base de données migre de SQL Server vers autre chose, mon code sera toujours viable tandis que ma requête stockée dans mon Dataset elle serait obsolète ??

Je dois également la comparer à ses concurrentes, à savoir visiblement Hibernate.

Tout ceci est encore très flou pour moi...

Je vous remercie d'avance pour les précisions et réponses que vous pourriez m'apporter.

Marc

[sheitancrew]

J'ai aussi la possibilité d'étudier Linq to Entities à la place de Linq to SQL mais j'ai les mêmes difficultés à assimiler ce concept....


Encore merci d'avance, je suis au fond la ...!

[Er3van]

Je pense que tu auras la réponse à la plupart de tes questions ici, on en a débattu très récemment.

Et c'est plutôt NHibernate en .Net, mais ce n'est pas forcément un "concurrent".

Disons que tu as plusieurs approches :
- Procédure stockées
- Linq to SQL (pour moi sur la voie de l’obsolescence)
- Linq to Entities (Entity Framework)
- NHibernate
- ...

Qui se justifient en fonction de pas mal de critères :
- Taille du projet
- Volume et structure de la base données
- Orientation performance forte ou faible
- Délais/planning du projet
- Compétence de l'équipe en SQL et/ou ORM
- ...

[tomlev]

Linq to SQL est un ORM, c'est à dire qu'il fait le lien entre un modèle objet (des classes) et un modèle physique de données (la base de données).

Linq to SQL tire partie de Linq (Language INtegrated Query), une fonctionnalité de C# qui permet d'effectuer des requêtes sur des modèles objet. Linq to SQL convertit la requête C# "objet" en requête SQL, exécute la requête sur la base de données, et matérialise le résultat sous forme d'objets.

Les DataSets typés n'ont pas grand chose à voir avec ça, malgré les apparences... Quand tu fais un Fill d'un DataSet, ça exécute une requête SQL prédéfinie (habituellement générée par le designer), et ça charge le résultat dans les DataTables. Ensuite tu travailles sur ces données en mémoire, et c'est seulement quand tu as fini de travailler dessus que tu appliques les changements à la base de données : c'est ce qu'on appelle le mode déconnecté.

Avec Linq to SQL, on travaille en mode connecté. On manipule directement la base de données, pas une copie en mémoire des données. Ca s'utilise de façon beaucoup plus naturelle : ton code C# représente la requête qui sera exécutée en base (alors qu'avec un DataSet tu fais simplement appel à Fill, pour voir à quoi ça correspond il faut que tu ailles voir la définition du DataAdapter).

Soit dit en passant, Linq to SQL est obsolète (ou en passe de le devenir ; il me semble que MS a annoncé que c'était abandonné) : il faut utiliser Entity Framework (aka Linq to Entities). Le principe est le même, mais il y a au moins 2 avantages importants :

• ça peut marcher avec n'importe quel SGBD, pas seulement SQL Server ; il faut juste qu'il existe un provider Entity Framework pour ce SGBD, mais la plupart des éditeurs en fournissent un (Oracle est encore à la bourre, mais je crois qu'ils travaillent dessus)
• on peut modéliser les données de façon beaucoup plus souple que dans Linq to SQL, notamment pour les associations N-N et l'héritage

[sheitancrew]

Merci à vous.
Après avoir consulté le post suggéré ainsi que vos remarques, j'en conclue que je vais plus m'orienter vers une présentation et une utilisation de Linq to Entities.

Pour ma part ces informations très interessantes auraient méritées d'être un peu plus vulgarisées.

Je n'ai en revanche pas trouvé de points forts par rapport à NHibernate..

Merci

[Er3van]

Pour ma part ces informations très interessantes auraient méritées d'être un peu plus vulgarisées.

Lesquelles ? Etant donné la complexité réelle de cache un ORM, difficile de rentrer dans le détail et de parler des avantages/inconvénients sans utiliser les termes "code généré" ou "plan d'exécution"...

Je n'ai en revanche pas trouvé de points forts par rapport à NHibernate.

NHibernate c'est l'ORM des "gros projets".
Entity Framework, c'est l'ORM des "petits projets".

Entity Framework est facile à implémenter/utiliser, intégré dans le framework et donc interfacé dans Visual Studio, pratique pour faire des lectures à la volée, mais mauvais pour faire des opérations de masses (lecture/écriture/suppression de plusieurs dizaines de milliers de lignes).

NHibernate est plus configurable, plus "robuste" (encore que...), plus performant (encore que ça dépende de l'utilisation).

[sheitancrew]

Merci pour les différences NHibernate vs Linq to Entities, c'est ce que j'avais cru comprendre, j'en ai confirmation.

Concernant la vulgarisation, c'est par exemple pour moi qui utilise depuis 1 an les Datasets, qu'est ce qui pourrait me convaincre de passer à Linq ?

Merci beaucoup

[tomlev]

Un éditeur tiers en propose un (j'ai plus la référence sous la main).

C'est DevArt

pratique pour faire des lectures à la volée, mais mauvais pour faire des opérations de masses (lecture/écriture/suppression de plusieurs dizaines de milliers de lignes).

On pourrait dire la même chose de tous les ORM, y compris NHibernate... si tu veux faire des opérations de masse, il vaut mieux les faire directement en SQL, ou même en procédure stockée

[WOLO Laurent]

Pour vous faire une idée sur les perfs des ORM, clique ici vous trouverez ca sur ce poste

[Nathanael Marchand]

Oracle est encore à la bourre, mais je crois qu'ils travaillent dessus

Il est actuellement en beta publique
Un éditeur tiers en propose un (j'ai plus la référence sous la main).