Discussion :

[RaelRiaK]

Bonjour,

Dans la vie de tous developpeurs, il convient de se poser des questions sur l'avenir. J'ai consulté les vidéos du TDF 2007 sur les technologies .NET 3.5, et je suis pas mal intrigué par bon nombre de choses! Le sujet me perturbant le plus étant le suivant : LINQ !

Les possibilités sont certes trés impressionantes de simplicité, mais reste des zones d'ombre sur ce que MS s'attend à ce que nous en fassions :
- Es-ce censé remplacer ADO.net à terme ?
- Où placer ces appels d'un point de vue structurelle dans un schema cohérant de développement en couches (Data, Business, Applicatif, GUI ...) ?
- Que faire du développement SQL Server (proc, fct ...)

Parce que en voyant ca, la premiere chose que je me suis dis c'est "étrange, on nous incite quasiment a mettre du SQL version C# directement derriere les controle GUI", ce que pour ma part je trouve d'une cradeur infame (j'en connais malheureusement qui ne font que ca!)

Parce que en clair, on creer un objet qui represente la base de données qui comprends sa structure et on interroge la table directement, ce qui nous renvoie un objet utilisable... Ce qui signifie "plus besoin de passer par des proc SQL, j'attaque les tables direct comme en Access 97 comme ca c'est plus simple" ...

Alors je suis certains que l'on peu faire beaucoup de choses interessantes, c'est pour cela que je poste , mais quoi dans un vrai developpement de client riche avec au moins 3 couches? Votre avis m'interesse

Renaud

[neo.51]

Bonjour,

LINQ ne peut pas remplacer ADO.NET car LINQ s'appuie sur ADO.NET pour fonctionner (du moins LINQ to sql).

Pour moi LINQ c'est surtout 2 choses :
-Un formidable framework de mapping o/r trés bien intégré au framework .NET.
-Un langage de réqêtage universel (en bd, en mémoire, en xml,...).

Le gros avantage que je vois dans LINQ c'est qu'on va enfin pouvoir faire des DAL propres assité par l'IDE et enterrer le dataset à terme. J'ai pas envie de rerererererevenir sur pourquoi j'aime pas les dataset mais LINQ (avec les assistants VS) va nous permettre de créer des classes propres, qu'on mappera sur la BD par attribut ou fichier externe. Sur ces collections de classes on pourra faire des requêtes type sql (bien plus puissant qu'une dataview) et gérer le mise à jours en base aussi facilement qu'avec un adapter. Je suis en train de tester LINQ, j'ai donc pour l'instant une vision assez optimiste de la chose, mais pas de réèle expérience sur le sujet (ça risque de vite vennir). Ce qui est sur c'est que sur le papier LINQ répond à pas mal de problématiques que je me pose depuis que je développe en .NET, par exemple : http://www.developpez.net/forums/sho...d.php?t=199983

Parce que en voyant ca, la premiere chose que je me suis dis c'est "étrange, on nous incite quasiment a mettre du SQL version C# directement derriere les controle GUI", ce que pour ma part je trouve d'une cradeur infame (j'en connais malheureusement qui ne font que ca!)

Ben c'est des démos, dans toutes les démos la séparation des couches on la voit rarement....

Parce que en clair, on creer un objet qui represente la base de données qui comprends sa structure et on interroge la table directement, ce qui nous renvoie un objet utilisable... Ce qui signifie "plus besoin de passer par des proc SQL, j'attaque les tables direct comme en Access 97 comme ca c'est plus simple" ...

Faudra faire attention à cette apparente facilité qui peut induire des baisses de perfs importantes du genre :
On prend une table client une table commandes.
-Je charge mes 500 clients.
-Je parcours mes 500 client pour avoir leurs commandes
=>On éxécute 500 requêtes sql
... mais LINQ à tout prévu et je peux dire que je charge les commandes en même temps que les clients. C'est juste qu'il va falloir faire trés attention à ce genre de cas de figure et ne pas oublier les fondamentaux devant la simplicitée apparente du code

Alors je suis certains que l'on peu faire beaucoup de choses interessantes, c'est pour cela que je poste , mais quoi dans un vrai developpement de client riche avec au moins 3 couches? Votre avis m'interesse

Le développement de la couche d'accés aux données me semble plus cohérent avec LINQ qu'avec les solutions dataset de microsoft. Des classes maisons, mappés sur une DB, avec un mode de requêtage unifié. La possibilitée de faire des requêtes sur des objets en mémoire, bref j'ai vraiment l'impression que LINQ va m'apporter tous les outils pour bien construire ma DAL. Aprés LINQ ne fait pas tout et il faudra surement bien apréhender cette techno pour faire quelque chose de propre qui va plus loin qu'une démo pour faire une vue maître\détail.

La grosse intérogation c'est les performances de tout ça, et surtout le support des différents SGBD et provider ADO.NET (et oui on dev pas tous sous sql-server)

[The_badger_man]

- Que faire du développement SQL Server (proc, fct ...)

on le garde et on l'utilise avec LINQ !
si tu as une procédure stockée qui te sert à ajouter un client (par exemple) tu peux spécifier à LINQ de l'utiliser quand tu créera un nouveau client afin qu'il évite de générer du SQL.

[Thomas Lebrun]

La grosse intérogation c'est les performances de tout ça

Rico Mariani a écrit une série de 5 post sur les performances de LINQ To SQL: http://blogs.msdn.com/ricom/default.aspx

Ils sont très instructifs à lire

[neo.51]

Bon ben grosse décéption en éssayant la béta 2 de LINQ : LINQ ne supporte pas oracle ni access, sql server only.

Le modèle étant "ouvert" je pense qu'oracle va finir par implémenter ça dans ODP.NET mais pour l'instant pas de roadmap sur le sujet.

C'est quand même fort que même OLEDB ne soit pas supporté... j'espère que ça sera réglé dans la béta 2... Tom tu sais ce qui est prévu à ce sujet ?

[RaelRiaK]

Bonjour,

J'ai réfléchi.
Pour ma part, cela fait 1 ans que je developpe avec mes propres libraires (comme tout le monde en fait). Cette librairie me permet de creer des dataset par interface graphique Visual 2005, et de modifier les DataView resultant en Collection do'bjet spécifique et en objet spécifique que je bind encore une fois par interface graphique Visual 2005 sur mes formulaire quelques couches plus haut.

Avec LINQ, l'avantage est que dés le rapatriement des données, on a une approche objet et non un simili DataView(1)(0) qui designe la premiere colonne de ma seconde ligne ...

Donc en clair on peut trés bien imaginer un appel LINQ sur constructeur d'un objet metier qui rapatrie les données demandées ...

Mais là encore la question me chiffone : si on nous pousse à faire les filtres regroupements depuis le client riche au lieu de le faire depuis le serveur SQL, cela ne va-t-il poluer un tant soit peu nos applications ? Bien sur il y a des cas spécifiques tel l'affichage d'une liste de données qui permettra de trier, de regrouper ... la collection sans faire de nouveau appel au serveur SQL. Mais dans le reste des cas?

J'espere me faire comprendre correctement

Merci pour vos réponses en tout cas.

Renaud

[neo.51]

Mais là encore la question me chiffone : si on nous pousse à faire les filtres regroupements depuis le client riche au lieu de le faire depuis le serveur SQL, cela ne va-t-il poluer un tant soit peu nos applications ? Bien sur il y a des cas spécifiques tel l'affichage d'une liste de données qui permettra de trier, de regrouper ... la collection sans faire de nouveau appel au serveur SQL. Mais dans le reste des cas?

On pousse pas on propose les outils

Le truc c'est qu'avant pour filtrer des données en mémoire y avait la méthode simple version dataview, la version on code et on implémente les différents filtres sur nos collections. Avoir un système de requêtage objet sur les objets en mémoire y a pas à dire c'est quand même super pratique... ça va être plus facile de gérer les caches objet.

Aprés LINQ c'est un outil, pas une boite magique qui fait tout tout seul, je pense qu'il y aurra quelques travers à éviter

[Thomas Lebrun]

C'est quand même fort que même OLEDB ne soit pas supporté... j'espère que ça sera réglé dans la béta 2... Tom tu sais ce qui est prévu à ce sujet ?

Nop, pas de news la-dessus. Mais que ce soit SQL Server only ne me surprendrait pas outre mesure...

[RaelRiaK]

On pousse pas on propose les outils

Le truc c'est qu'avant pour filtrer des données en mémoire y avait la méthode simple version dataview, la version on code et on implémente les différents filtres sur nos collections. Avoir un système de requêtage objet sur les objets en mémoire y a pas à dire c'est quand même super pratique... ça va être plus facile de gérer les caches objet.

Aprés LINQ c'est un outil, pas une boite magique qui fait tout tout seul, je pense qu'il y aurra quelques travers à éviter

Tout à fait d'accord. Mais loin de moi l'idée de critiquer cela, parce honnetement je vois un interet phenomenal à pouvoir trier et regrouper mes collections sans avoir à developper de méthode spécifique!

En fait lorsque l'on va raptrier ses données depuis le serveur, on utilisera nos objets serveur, puis lors de la manipulation de ses objets (lorsque les data sont déjà sur place) on les manipule par LINQ. Cette approche me plait!
Dans la vidéo de présentation de LINQ, il nous montre comment résoudre un probléme qui sans proc tiendrait en 200 lignes ... Oui mais on passe par des proc en générale justement.

Mais honnétement plus j'y pense plus j'y vois un interet majeur.
Merci en tout cas.

[neo.51]

Nop, pas de news la-dessus. Mais que ce soit SQL Server only ne me surprendrait pas outre mesure...

Microsoft fournis 4 providers :
-sqlclient
-oledb
-oracle
-adbc

S'ils supportent pas leurs propres providers, c'est un peu incohérent avec le fait de dire que LINQ est construit sur un modèle ouvert qui permettra à tous les éditeurs de SGBD de réaliser facilement les extensions LINQ du provider ADO.NET.

Même si la grande majorité des développeurs dotnet sont sous sqlserver y en a encore un bon paquet sous access (bon ok de moins en moins) et sous oracle.

[tomlev]

Salut,

C'est un vieux sujet (le dernier post date d'il y a 9 mois...), mais je rebondis dessus parce que je commence à me poser des questions sur les providers LINQ tierce partie... ça commence à faire pas mal de temps qu'on parle de LINQ, c'est un outil qui a un potentiel impressionnant, et pourtant j'ai pas encore vu un seul provider "officiel" pour les principaux SGBD du marché.

Par exemple Oracle est un des SGBD les plus utilisés (sinon le plus utilisé), et tout ce que je trouve est un provider LINQ open-source (ici) dont je ne sais pas du tout s'il est stable et fiable... J'aimerais bien savoir si Oracle travaille à créer un provider LINQ, qui pourrait être inclus dans la prochaine version d'ODP.NET. J'ai vu un commentaire évasif à ce propos sur le blog de Mitsuru Furuta, mais rien de concret, et je n'ai pas trouvé de confirmation ailleurs...

En plus je ne comprends pas que Microsoft continue à se limiter au support de SQL Server. Ils pourraient au moins supporter SQL Server Compact ou ODBC, mais non, quedalle...

J'espérais que LINQ to Entities permettrait d'utiliser d'autres SGBD, mais apparemment ça s'appuie sur LINQ to SQL, donc ça résout pas le problème.

Bref, j'avais de grands espoirs pour LINQ, mais ça tarde à se concrétiser...

[Thomas Lebrun]

LINQ est malgré tout une technologie encore jeune: il faut laisser le temps aux éditeurs de sortir leur produits dessus.

J'espérais que LINQ to Entities permettrait d'utiliser d'autres SGBD, mais apparemment ça s'appuie sur LINQ to SQL, donc ça résout pas le problème.

LINQ To Entities s'appuie sur le même principe que LINQ To SQL mais permet bien d'attaquer n'importe quel SGBDR: cf ici http://blogs.msdn.com/benko/archive/...s-webcast.aspx

[tomlev]

LINQ To Entities s'appuie sur le même principe que LINQ To SQL mais permet bien d'attaquer n'importe quel SGBDR: cf ici http://blogs.msdn.com/benko/archive/...s-webcast.aspx

Ben quand on précise la source de données on peut choisir que SQL Server comme provider... Mais bon, c'est peut-être juste le Designer qui ne supporte que SQL Server ?

Merci, je vais regarder ton lien

EDIT: effectivement ils disent clairement qu'on peut utiliser d'autres SGBD... donc ça doit être une limitation du designer EDM. Après tout Entity Framework n'est pas encore en version finale... Je vais creuser un peu ça.

[Thomas Lebrun]

Ben quand on précise la source de données on peut choisir que SQL Server comme provider... Mais bon, c'est peut-être juste le Designer qui ne supporte que SQL Server ?

Merci, je vais regarder ton lien

EDIT: effectivement ils disent clairement qu'on peut utiliser d'autres SGBD... donc ça doit être une limitation du designer EDM. Après tout Entity Framework n'est pas encore en version finale... Je vais creuser un peu ça.

En effet, n'oublie pas que c'est encore une Beta pour le moment