Un grand tour d'horizon de LINQ et ses différentes versions

Le Tue, 11 Dec 2007 14:41:42 +0100, OD <webmaster e-naxos dot com> a
écrit:

Voici un nouvel article gratuit à télécharger, PDF de 32 pages avec 5
projets exemples sous VS 2008 pour comprendre les nombreuses facettes de
LINQ et ce qu'il peut changer dans votre façon de développer.
Pour accéder à l'article suivez ce minilien :
http://minilien.com/?xBv7W7vzJl

Sujets traités avec exemples : LINQ to Objects, LINQ to XML, LINQ to
ADO.NET (LINQ to SQL, LINQ to Dataset, LINQ to Entities).

Bonne lecture !

Bonjour,

Ton article est très interessant !
Il est vrai que malheureusement, tu ne peux pas rentrer trop dans les
détails de tout la syntaxe de LINQ (car comme tu l'as très bien dis, cela
risque de finir dans un bouquin de 500 pages...). Mais au moins tu donnes
une très bonne introduction sur Linq. Après il suffit d'avoir un bon FAI
et un bon navigateur et il reste plus qu'à surfer sur le MSDN !

Je voudrais juste faire une remarque concernant la dernière partie sur
Linq To Entities :
Tu dis qu'il faut utiliser le Designer de VS2008 "Linq To SQL", hors il me
semble que cela reste toujours du "Linq To SQL"... Et je ne vois guère la
différence a part que l'on utilise des objets générés automatiquement par
VS2008...

D'après ce que j'ai compris de Linq To Entities il s'utilise avec ADO .NET
Entity Framework (qui est au stade beta) et permet d'avoir des objets de
données que l'on place dans la couche métier et qui sont bien évidemment
indépendant de la source de données. Un peu comme les DataSet, à la
différence que c'est orienté 100% objet et non "rectangulaire" (au passage
dans ton article j'adore comment tu stéréotypes nos pauvres SGBD... ;-) ).

En fait je te fais cette remarque car après avoir lu cette article, je me
pose 2 questions :
- Pourquoi Microsoft a appellé le Designer "Linq To SQL Classes" pour
générer et utiliser du Linq To Entities ?
- Le designer génére 2 types de classe : un DataContext et une classe
objet. Ou doit-on mettre le code généré par le Designer ? (plus simplement
le fichier .dbml)
* Dans la couche d'accès aux données ? Ok, mais c'est la couche de
données qui définit alors les classe objets... Alors qu'elle devrait être
dans la couche métier....
* Dans la couche métier ? Ok, mais l'objet DataContext est fortement
couplé aux SGBD ! De plus, il me semble que dans la couche métier on
devrait s'interdir d'avoir une référence à System.Data.Linq qui est
spécifique à SQL et donc à une source de données particulière.

Est-ce que tu peux éclairer un peu plus ma lanterne ?

Aussi, est-ce que tu ne peux pas mettre une table des matières et des
titres numérotés dans ton article ?

En te remerciant par avance !

--
Gilles TOURREAU
gilles.tourreau@pos.fr

S.A.R.L. P.O.S
Le spécialiste en motoculture depuis + de 30 ans !
http://www.pos.fr

> Ton article est très interessant !

Merci Gilles

Il est vrai que malheureusement, tu ne peux pas rentrer trop dans les détails
de tout la syntaxe de LINQ (car comme tu l'as très bien dis, cela risque de
finir dans un bouquin de 500 pages...). Mais au moins tu donnes une très
bonne introduction sur Linq. Après il suffit d'avoir un bon FAI et un bon
navigateur et il reste plus qu'à surfer sur le MSDN !

Il y a plein de choses sur MSDN mais il faut remarquer que les sources
d'infos sont pour l'instant très légères, même sur la page du projet
LINQ chez MS on trouve des docs (syntaxe ou autre) qui sont datées.. de
2005 !
Je pense qu'il faut encore un peu de temps pour des docs plus complètes
arrivent.

Je voudrais juste faire une remarque concernant la dernière partie sur Linq
To Entities :
Tu dis qu'il faut utiliser le Designer de VS2008 "Linq To SQL", hors il me
semble que cela reste toujours du "Linq To SQL"... Et je ne vois guère la
différence a part que l'on utilise des objets générés automatiquement par
VS2008...

Linq to Entities c'est avant tout Linq to SQL avec quelques "plus". Le
designer visuel de l'Entity Data Model (EDM) et la génération
automatique du code en font partie (et c'est déjà fourni) mais il
manque encore quelques features pour que la différence entre les deux
techniques soient plus clairement marquée.
Par exemple, Linq to Entites devrait supporter les relations Many to
manu, alors que Linq to SQL ne sait pas le faire, de même sous Linq/E
on devrait pouvoir définir des entités par héritage ce qui n'est pas
possible encore. Enfin, Linq/E offre des possibilités de mapping bien
plus avancées permettant notamment de définir des entités dont les
champs proviennent non plus d'une seule table (limitation de Linq to
SQL et de l'actuelle "faux" Linq to Entities) mais de plusieurs.
C'est quand ces quelques ajouts seront enfin présents qu'on verra toute
l'énorme différence entre Linq/E et Linq/sql.

Il y a d'autres différences plus internes, par exemple Linq to Entities
repose sur un mapping exprimé totalement en XML et donc plus "ouvert",
alors que Linq to SQL et l'actuel "faux" Linq to Entities reposent sur
des attributs.

On peut donc dire que Linq to Entites, tel qu'il se présente dans VS
2008 c'est un peu un abus de langage, c'est un Linq to SQL amélioré
avec designer visuel. Mais quand les subtilités du mapping avancé avec
XML seront enfin dispos, on obtiendra bien un "vrai" Linq to Entities
très semblable d'aspect mais très différent en terme de fonctionnement.

(au passage
dans ton article j'adore comment tu stéréotypes nos pauvres SGBD... ;-) ).

Pour faire saisir la différence conceptuelle entre linq et les SGBD
j'avoue avoir un poil forcé le trait :-)

- Pourquoi Microsoft a appellé le Designer "Linq To SQL Classes" pour générer
et utiliser du Linq To Entities ?

parce que eux savent exactement la différence avec le "vrai" linq alors
que moi je l'ai un peu gommée dans mon article :-)
Différences qui justifient certainement de ne pas encore appeler Linq
to Entity ce qui est fourni. Techniquement ils ont parfaitement raison.

Du point de vue du concept et des outils (l'EDM et son designer par
ex), la nuance est plus légère ce qui justifie ma présentation dans
l'article, mais j'avoue que j'aurais pu avertir plus clairement de
cette subtile nuance entre "faux" et "vrai" Linq to Entities. Quelques
pages en plus :-)

- Le designer génére 2 types de classe : un DataContext et une classe objet.
Ou doit-on mettre le code généré par le Designer ? (plus simplement le
fichier .dbml)
* Dans la couche d'accès aux données ? Ok, mais c'est la couche de données
qui définit alors les classe objets... Alors qu'elle devrait être dans la
couche métier....
* Dans la couche métier ? Ok, mais l'objet DataContext est fortement
couplé aux SGBD ! De plus, il me semble que dans la couche métier on devrait
s'interdir d'avoir une référence à System.Data.Linq qui est spécifique à SQL
et donc à une source de données particulière.
Est-ce que tu peux éclairer un peu plus ma lanterne ?

Sur ces points précis je suis encore à m'interroger moi-même sur les
meilleures pratiques à appliquer. Linq bouleverse la donne en rendant
bien plus floue (et c'est son but!) la nuance entre objets et données
persistantes...
On voit bien qu'il suffit d'ajouter des méthodes dans les entités pour
en faire des classes métier.. Est-ce souhaitable ? Au final une entité
de l'EDM c'est à la fois un DAL et un BOL. On nous a bassiné sur
l'intérêt méthodologique de cette séparation pendant des années...
Faut-il l'abandonner ?
je crois surtout qu'il faut développer de nouveaux paradigmes. Mais
pour ça il faut de l'expérimentation. Et comme on le précisait ici, on
ne dispose pas encore du "vrai" Linq to Entities. Ce qui rend cette
expérimentation un peu prématurée, ainsi que les conclusions qu'on peut
en tirer.
Pour le moment on peut utiliser pleinement Linq to SQL avec un designer
visuel très pratique. De fait, je serais tenté de dire qu'on s'arrête à
un DAL. Mais de quelques projets que j'ai déjà entamés avec Linq je
m'aperçois que créer une couche BOL en plus est un peu 'artificiel' et
alourdi le code pour un gain théorique et méthodologique qui se discute
franchement.. Moralité : je m'interroge encore :-)

Aussi, est-ce que tu ne peux pas mettre une table des matières et des titres
numérotés dans ton article ?
En te remerciant par avance !

Pour l'article sur Linq j'avoue que ça serait utile vu la longueur.
Mais je me suis fait avoir à mon propre jeu et je ne pensais pas au
départ en écrire autant pour un simple tour d'horizon.
Le corbeau honteux et confus... tu connais la suite :-)

--


OD___
www.e-naxos.com

Le Wed, 12 Dec 2007 19:53:02 +0100, OD <webmaster e-naxos dot com> a
écrit:

En fait je crois que tu confonds le Designer "Linq/SQL classes" et le
designer "Linq/E classes" (que l'on télécharge à part).

Dans ton article à la partie Linq/E, c'est que tu expliques bien le
problème entre le mixage du modèle objet et relationnel.
Tu expliques clairement que l'on voudrait mieux utiliser le MCD de la base
de données qui représente plus notre problème de manière "naturelle".
Jusqu'à là je suis d'accord avec toi...

Maintenant, tu dis dans ton article pour Linq/E qu'il faut utiliser le
designer Linq/SQL. Or, avec le Linq/SQL (et tu l'a bien dis dans le
précédent post) il n'est pas possible de faire des relations many/many,
mais uniquement des relations 1-N. Je suis d'accord avec toi.
Mais on se retrouve alors à faire du mapping objet, reflétant exactement
la structure de la base de données comme les DataSet...
Donc je ne vois pas pourquoi tu mets le Designer Linq/SQL dans la partie
Linq/E, et surtout pourquoi tu fais la différence entre un "faux" et
"vrai" Linq/E....

Pour moi Linq/E est utiliser par le Framework ADO .NET Entity Framework à
part disponible ici :
http://msdn2.microsoft.com/en-us/library/bb896679.aspx

Et qu'il dispose aussi d'un autre Designer pour VS 2008 RTM
(téléchargeable dans la rubrique Entity Model Tools) du lien précédent.
En utilisant ce designer, on s'aperçoit que l'on a comme tu l'as dis
précédement un mapping XML, mais aussi un modèle 100% objet (ou les
relations many/many sont possibles et que l'on peut mapper en une table).

Ce que je veux dire, c'est que j'ai plus l'impression que ta partie
"Linq/E" qui concerne le Designer de Linq/SQL devrait être dans la partie
Linq/SQL et que tu devrais plustôt parler dans la 3ème partie de l'autre
Designer du ADO .NET Entity Framework qui utilise Linq/E...

Sur ces points précis je suis encore à m'interroger moi-même sur les
meilleures pratiques à appliquer. Linq bouleverse la donne en rendant
bien plus floue (et c'est son but!) la nuance entre objets et données
persistantes...
On voit bien qu'il suffit d'ajouter des méthodes dans les entités pour
en faire des classes métier.. Est-ce souhaitable ? Au final une entité
de l'EDM c'est à la fois un DAL et un BOL. On nous a bassiné sur
l'intérêt méthodologique de cette séparation pendant des années...
Faut-il l'abandonner ?
je crois surtout qu'il faut développer de nouveaux paradigmes. Mais pour
ça il faut de l'expérimentation. Et comme on le précisait ici, on ne
dispose pas encore du "vrai" Linq to Entities. Ce qui rend cette
expérimentation un peu prématurée, ainsi que les conclusions qu'on peut
en tirer.
Pour le moment on peut utiliser pleinement Linq to SQL avec un designer
visuel très pratique. De fait, je serais tenté de dire qu'on s'arrête à
un DAL. Mais de quelques projets que j'ai déjà entamés avec Linq je
m'aperçois que créer une couche BOL en plus est un peu 'artificiel' et
alourdi le code pour un gain théorique et méthodologique qui se discute
franchement.. Moralité : je m'interroge encore :-)

Pour moi, en consultant les forums anglais de Linq/SQL, je m'aperçois
comme toi que le Linq/SQL regroupe la couche DAL et BOL. Cela permet un
développement beaucoup plus rapide, mais orienté à 100% sur du
relationnel...

A la différence de Linq/Entities (avec le Framework ADO .NET Entity
Framework) permet toujours le découpage en couche...
Seulement, les objets générées par le designer se situe au niveau du BOL
et dans le DAL on retrouve uniquement les fichiers XML de Mapping et les
bibliothèques implémentant le fournisseurs sous-jacent que l'on utilise...

Cordialement

--
Gilles TOURREAU
gilles.tourreau@pos.fr

S.A.R.L. P.O.S
Le spécialiste en motoculture depuis + de 30 ans !
http://www.pos.fr

> En fait je crois que tu confonds le Designer "Linq/SQL classes" et le
designer "Linq/E classes" (que l'on télécharge à part).

Je ne les confond pas, mais comme je le dis dans le post précedent,
j'ai volontairement gommé la nuance car si elle très importante
techniquement, cosmétiquement et du point de vue du développement on
travaille dans les deux cas avec un modèle selon une philosophie très
proche. Actuellement le modèle possède un mapping de type Linq to SQL,
sous Linq to Entities, le mapping est plus sophistiqué. C'est
finalement l'unique vraie différence.
Elle est fondamental à plus d'un titre sur le plan technique, mais j'ai
jugé, peut être à tort, que s'embarquer dans ces nuances là justement
n'étaient pas du ressort d'une simple présentation des diverses
possibilités de linq.
je devrais réécrire l'article je placerais certainement un petit
paragraphe d'alerte prévenant de cette nuance entre le Linq to Entities
définitif, et ce qui lui ressemble dans la RTM de VS2008 qui n'est
qu'une version simplifiée.
Je vais l'ajouter d'ailleurs ce paragraphe, l'article sera plus précis.

Mais on se retrouve alors à faire du mapping objet, reflétant exactement la
structure de la base de données comme les DataSet...

tant que Linq to Entities n'est pas totalement opérationel c'est vrai,
mais avec une énorme nuance : avec le dataset tout est en mémoire, avec
les classes Linq to Sql, on travaille déjà dans la philosophie de Linq
to Entities, aux nuances de mapping déjà évoquées.

Donc je ne vois pas pourquoi tu mets le Designer Linq/SQL dans la partie
Linq/E, et surtout pourquoi tu fais la différence entre un "faux" et "vrai"
Linq/E....

C'est une approche "pragmatique" choisie pour le "tour d'horizon".
C'est vrai que, comme tout choix simplificateur, il est discutable.
Sciences & vie, sciences et avenir et consors reçoivent chaque mois du
courrier de gens qui se plaignent de certains choix simplificateurs de
ce genre. Je crois que c'est le lot de tout article de "vulgarisation",
et mon article en était ouvertement un, surtout pas un cours sur Linq.
Mais je vais ajouter dans la partie Linq to Entites l'avertissement
évoqué plus haut, ça sera plus clair.

Pour moi Linq/E est utiliser par le Framework ADO .NET Entity Framework à
part disponible ici :
http://msdn2.microsoft.com/en-us/library/bb896679.aspx

techniquement c'est tout à fait exact.

En utilisant ce designer, on s'aperçoit que l'on a comme tu l'as dis
précédement un mapping XML, mais aussi un modèle 100% objet (ou les relations
many/many sont possibles et que l'on peut mapper en une table).

C'est en effet la seule nuance entre ce qui est livré dans la RTM de
VS2008 et le "vrai" entity framework + Linq to Entities.
C'est essentiel techniquement, mais ça l'est moins pour les
explications dans un tour d'horizon. C'est en tout cas mon sentiment et
le choix que j'ai fait, une fois encore certainement criticable comme
toute simplication peut l'être.

Ce que je veux dire, c'est que j'ai plus l'impression que ta partie "Linq/E"
qui concerne le Designer de Linq/SQL devrait être dans la partie Linq/SQL et
que tu devrais plustôt parler dans la 3ème partie de l'autre Designer du ADO
.NET Entity Framework qui utilise Linq/E...

Tu as raison, mais j'avoue avoir été content d'écrire le mot
"conclusion" en bas de l'article que je trouvais trop court pour
vraiment parler de chaque chose et finalement trop long pour une simple
présentation.
Erreur d'évaluation dans la tâche donc découpage criticable... Mais ce
n'est pas le dernier article que j'écris sur le sujet. Je pense que
l'entity framework définitif avec linq to Entities méritent largement
un traitement à part.

Pour moi, en consultant les forums anglais de Linq/SQL, je m'aperçois comme
toi que le Linq/SQL regroupe la couche DAL et BOL. Cela permet un
développement beaucoup plus rapide, mais orienté à 100% sur du relationnel...

C'est ça qui peut déranger ou obliger à développer dans un style
particulier.
Les expériences que j'en fait en ce moment me prouve que pour tout ce
est du ressort de l'informatique de gestion (dans sa plus large
acceptation), c'est un mode de développement très efficace. Ce sont des
applications très "data centric" et ce mode leur convient pas mal. Je
reste, faute de recul, plus réservé sur l'adéquation de ce style avec
d'autres formes de logiciels. Il faudra voir à l'usage. Mais Linq to
Entities (avec l'EF) est plus versatile et plus objet, je pense qu'à
terme je n'utiliserais plus que EF. Linq to SQL ne m'apparaît que comme
un intermédiaire sur le chemin de EF.

A la différence de Linq/Entities (avec le Framework ADO .NET Entity
Framework) permet toujours le découpage en couche...
Seulement, les objets générées par le designer se situe au niveau du BOL et
dans le DAL on retrouve uniquement les fichiers XML de Mapping et les
bibliothèques implémentant le fournisseurs sous-jacent que l'on utilise...

c'est pour ça qu'il me semble que Linq to sql n'est qu'une sorte de
preview limitée de EF + Linq to Entities. Quel sera la durée de vie de
Linq to SQL une fois EF et Linq/E en version final ? A mon sens le
premier s'effacera au profit du second. Mais on verra, je n'ai pas de
boule de cristal non plus..

--


OD___
www.e-naxos.com

J'ai fait quelques modifs à la section Linq to Entities, j'en ai
profité pour ajouter une table des matières tu seras content :-)
Si tu as le temps regarde la partie Linq to Entities et dis moi si les
modifs de l'article te paraissent éclaircir les choses ou les
embrouiller...

--


OD___
www.e-naxos.com

Le Thu, 13 Dec 2007 04:35:36 +0100, OD <webmaster e-naxos dot com> a
écrit:

J'ai fait quelques modifs à la section Linq to Entities, j'en ai profité
pour ajouter une table des matières tu seras content :-)
Si tu as le temps regarde la partie Linq to Entities et dis moi si les
modifs de l'article te paraissent éclaircir les choses ou les
embrouiller...

Voilà qui en fait un très bon article !
Maintenant les débutants se mélangeront moins les pinceaux !

Cordialement

--
Gilles TOURREAU
gilles.tourreau@pos.fr

S.A.R.L. P.O.S
Le spécialiste en motoculture depuis + de 30 ans !
http://www.pos.fr

> Voilà qui en fait un très bon article !
Maintenant les débutants se mélangeront moins les pinceaux !

merci. A force de relire les corrections j'avais peur d'avoir
finalement embrouillé les choses.. ça me rassure un peu (un peu
seulement parce que tu n'as pas vraiment le profil du débutant type..).

Bon week end.

--


OD___
www.e-naxos.com