Discussion :

[hmimoud]

Salut
Source: http://fr.wikipedia.org/wiki/Language_Integrated_Query

En bref, c'est un langage qui permet la "convertion" des tables d'une BD en objets "classes", ce qui nous permet d'utiliser l'objet plus une syntaxe linq to sql proche du sql au lieu d'instructions sql pures.

Que pensez vous de linq to sql ?

Merci

[Philippe Vialatte]

Salut,

En bref, c'est un langage qui permet la "convertion" des tables d'une BD en objets "classes", ce qui nous permet d'utiliser l'objet plus une syntaxe linq to sql proche du sql au lieu d'instructions sql pures.

Euh, oui, si on veut, et si on réduit le scope à linq to sql.

Que pensez vous de linq to sql ?

Que c'était très bien en 2008...pour faire une démo

Bon, plus sérieusement, si:
- l'appli est simple
- la base de données est SQL Server

Linq To SQL est très bien...sauf que, par expérience, sur la durée de vie d'un projet, une appli reste rarement "simple", et que, sur la durée de vie d'une société, dire que la base de données est et restera sql server ne se vérifie pas forcément

Donc, personnellement, j’évite Linq To SQL comme la peste

Par contre, Linq to NHibernate, Subsonic 3, EF, ou autre, pourquoi pas

[moubarmij]

Beaucoup de sociétés utilisent linq to sql comme outil pour éditer les logiciels.
Ils peut y avoir des logiciels trop complexe dans leurs utilisation mais très simple dans leurs éditions surtout avec linq to sql ainsi que d'autre solutions.

Encore faut il savoir utiliser cet outil avec intelligence et surtout ne pas sous-estimer et oublier le langage sql qui reste un langage phare et standart

[hmimoud]

Il faut aussi se mefier de la couche abstraite qui gere la dite "conversion" par le moteur!

[iberserk]

LINQ TO SQL est 'obsolète', voyez LINQ TO ENTITIES...

En tant que dba... je préfère un bon vieil ADO.NET plus performant que n'importe quel ORM type Linq TO ENTITIES ou NHIBERNATE...

C'est malgré tout un bon outil... s'il est bien utilisé par les développeurs mais là c'est une autre histoire

[WOLO Laurent]

Franchement, je n'aime pas les ORM, il est difficile de faire des applications performantes avec les ORM, ce sont des outils bien pour faire un programme rapide afin de livrer une application dans les delais, pour ceux qui ont la maîtrise d'ADO.Net et du language SQL, un ORM risque d'être une mauvaise solution pour un projet sérieux.

[SQLpro]

Que pensez vous de linq to sql ?
Merci

Rien !!!!

PUISQU'IL A ÉTÉ ABANDONNÉ pas son créateur Microsoft !!!!!

A lire :
http://patricelamarche.net/2008/11/0...st-mort-suite/

Bien évidemment ce que je pense des ORM pour les avoir cotoyés dans de nombreux audit et vu des sociétés faire faillite à cause de ce genre de merde est assez simple et a été dit maint fois par d'autre :
L'ORM est le Vietnâm de l'informatique
Tout le monde s'y met parce que ça semble fastoche et finalement s'y embourbe et ça coute dix fois plus cher en maintenance !

A +

[Er3van]

L'ORM est le Vietnâm de l'informatique
Tout le monde s'y met parce que ça semble fastoche et finalement s'y embourbe et ça coute dix fois plus cher en maintenance !

Cela a été débattu longuement ici, et je trouve cette vision très partiale et réductrice... Comme cela été dit, dans un contexte donné, et avec un niveau de compétences et de qualité suffisant (cela fait quand même des contraintes fortes), utiliser des ORM est tout à fait viable.

[Philippe Vialatte]

Tiens, un troll

Rien !!!!

PUISQU'IL A ÉTÉ ABANDONNÉ pas son créateur Microsoft !!!!!

A lire :
http://patricelamarche.net/2008/11/0...st-mort-suite/

Mouais...
http://msdn.microsoft.com/en-us/data/bb525059.aspx#Q3

vu des sociétés faire faillite à cause de ce genre de merde

Hmmm....donc, utiliser mal un outil veut dire qu'il est fondamentalement mauvais...

Sous entendu, je peux faire une procédure stockée qui me plante la db, ou une requête SQL qui fait un delete en oubliant le Where, donc SQL est mauvais, c'est ca l'idée ???

Personnellement, j'ai vu des sociétés faire faillite à cause:
- de mauvais placements (arrêtons de mettre des sociétés en bourse)
- de mauvais choix de stratégie (arrêtons de mettre en place des stratégies)
- du décès du fondateur (arrêtons de mourir)

Plus sérieusement, oui, comme dit...euh...au tout début de la discussion, tant qu'a utiliser un ORM, autant utiliser autre chose que Linq To SQL (ne serait-ce que pour la contrainte d'utilisation de SQL Server)

Pour l'histoire du "Vietnam de l'informatique", j'en déduit que tu as lu l'article d'origine, et compris l'analyse qui était développé, à savoir que les ORM, comme tout outil (dont une base de données relationelles) ont des limites d'utilisation, et qu'une mise en place "absolue" fait rentrer l'organisation qui s'y astreint dans une situation inconfortable, à partir du moment ou ces limites sont atteintes.

...d'ou les nombreuses remarques dans les posts précédents, qui veut que, dans le cas d'un ORM, on utilise son cerveau pour l'utiliser dans les 80% des cas ou cela à un interet, et on fait autre chose dans les autres cas

[Immobilis]

Salut,

Juste pour voir, si certains d'entre vous ont du Linq to Sql dans leur applications, pouvez-vous vérifier si vous suivez les recommandations listées au bout de ce lien: http://www.sidarok.com/web/blog/cont...rformance.html

A+

[Immobilis]

Salut,

Cette discussion m'a un peu poussé à rédiger ce papier: http://immobilis.developpez.com/tuto...ity-framework/

J'y teste plusieurs implémentations de fournisseurs de données. Ce papier n'est pas encore officiellement publié et je serais très intéressé de recueillir vos commentaires, suggestions.

Merci d'avance.

Immo

[Er3van]

Très intéressant ! (Par contre c'est technique, faut s'accrocher pour suivre dans le détail, mais vu le sujet c'est logique :p)

Par contre, il serait intéressant de préciser les versions des providers (par exemple, EF 3.5, EF 4, EF 4.1 ?) et éventuellement de faire le même test avec une base "indépendante" du framework .Net comme Oracle.

[WOLO Laurent]

Vous avez écrit un excellent article qui permettrait aux personnes rigoureusent en matière de perf de pouvoir tirer meilleurs partie sur l'utilisation de linq.

Deuxièmement, d'après les tests, les fournisseurs " Linq + SP ", " Linq + Cmd " et " Linq to Entities " sont sur certains points plus rapides que le Sql traditionnel. Cela mériterait toutefois d'être testé plus en profondeur dans un environnement de production.

Toutefois il faut que tu fasses ressortir des tests qui pouverais que Linq + Cmd par exemple serait plus rapide que le SQL Standard