Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Linq to sql : Avis
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
Salut,
Euh, oui, si on veut, et si on réduit le scope à linq to sql.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 c'était très bien en 2008...pour faire une démoQue pensez vous de linq to sql ?
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
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
Il faut aussi se mefier de la couche abstraite qui gere la dite "conversion" par le moteur!
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
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.
On ne va pas nourrir le troll sur les ORM, mais c'est clairement un point de désaccord entre développeurs et DBAs.Envoyé par WOLO Laurent
Personnellement, je n'ai pas de pb avec mon DBA parce que:
- j'utilise des ORM pour des fonctionnalités qui sont "simple" (CRUD + des requetes avec 3 jointures max)
- je profile mes applications avant la mise en prod
Si un développeur code en SQL comme un pied, ou avec un ORM comme un pied, le résultat sera de toute façon désastreux, alors...
Aprés, je ne sais pas ou tu places le curseur d'un projet sérieux, mais comme j'ai rarement vu mes clients au festival du rire
je ne sais pas ou tu places le curseur d'un projet sérieux, mais comme j'ai rarement vu mes clients au festival du rire
Je crois que nous n'allons pas faire un débat sur les ORM versus le code SQL.
Et pourquoi pas !
En plus, le développement informatique évolue quotidiennement afin de procurer au développeurs des solutions ingénieuses et plus approprié au développeurs pour faire des applications ingénieuses. C'est comme l’évolution du langage d'instructions (C & co) vers langage objet. Toutefois,les ORMs ne sont pas propres qu'aux developpeurs puisqu'ils utilisent un langage proche de celui de sql
, que ce soit l'un ou l'autre, ce qui compte c'est l'informaticien
, cet etre qui est capable de créer des programmes avec du code que nul autre ne peut comprendre que ce soit sql ou langage de programmation
.
Faisant abstraction au domaine informatique, le resultat final s'avere le plus important à l'oeil de l'utilisateur: "l'objectif principale et la raison d'etre d'un developpeur".
En fin de compte, les developpeurs et les DBAs sont complementaires pour developper une application complete et performante.
Le developpeur voudra utiliser un ORM pour aller vite tandis qu'un DBA souhaiterait contrôller le code SQl générer. J'avoue qu'il faut un developpeur avec suffisamment d'expérience en SQL pour tirer meilleur parti d'un ORM sachant qu'il pourra toujours dévier les pitfalls engendrer par la mauvaise utilisation d'un ORM.
A fool with a tool is still a fool!
Retrouvez moi sur :
Mon Espace Developpez.com-------------------------------
A fool without a tool is a toolless fool
Oui, tout à fait d'accord sur ton point.
De toute façon, un développeur qui ne maitrise pas les bases du SQL (et quand je dis les bases, c'est quelqu'un qui connait la différence entre 3NF et FNBC, avec incluant des notions de tuning de requête) ira droit dans le mur quand on lui demandera de produire une procédure stockée modérément complexe, donc c'est le serpent qui se mord la queue...
En fait, je souhaite surtout attirer l'attention sur le fait qu'il faut faire attention avec la publicité, la réalité c'est à dire la pratique peut être une autre histoire.
Les ORM, comme le SQL sont des outils que l'on maitrise ... Ou pas.
On avait un énorme graphe d'objet dans une application stocké sur 3 tables.
Un colegue "à l'ancienne" (qui fait partie de ceux qui critiques les perfs des ORM sans réellement comprendre le fonctionnement) avait une requête procstock pour charger tout ça (avec 2 left outer join entre les tables).
La requete mettait 8 s à s'éxécuter.
J’ai refait la requête pour charger les même données en EntityFramework et j'ai pu charger les mêmes données en moins d'une seconde.
EntityFramework et (la plupart) d'autres framework ORM sont très performant ... Quand on sait les utiliser.
Bien dis !Les ORM, comme le SQL sont des outils que l'on maitrise ... Ou pas.
On avait un énorme graphe d'objet dans une application stocké sur 3 tables.
Un colegue "à l'ancienne" (qui fait partie de ceux qui critiques les perfs des ORM sans réellement comprendre le fonctionnement) avait une requête procstock pour charger tout ça (avec 2 left outer join entre les tables).
La requete mettait 8 s à s'éxécuter.
J’ai refait la requête pour charger les même données en EntityFramework et j'ai pu charger les mêmes données en moins d'une seconde.
EntityFramework comme (la plupart) d'autres framework ORM sont très performant ... Quand on sait les utiliser.
Il ne faut pas considérer le sql comme un monstre quand même !
En théorie, vous ne pouvez normalement pas faire plus rapide via un ORM que via SQL Directement puis que l'ORM doit faire de la traduction en SQL sans oublier les pars avant d'envoyer le code chez SGBDR, le problème c'est alors ton collègue qui était fatigué ce jour là, mais je reprécise que vous ne pouvez pas faire plus rapide, essayez donc de m'en faire la démonstration si je me trompe.
Moi je parle pas de théorie, je parle de pratique, de pragmatisme.
Certes les ORM génère du sql mais ce sql est optimisé et on peut faire plus facilement des choses qui serait compliqué. De plus un "mauvais loading" est facile a trouver et a optimiser.
Et je ne parle pas des applications qui se contente de faire les procs stock (tt de même chiante a maintenir) CRUD avec GetAll et GetById et ensuite font des centaine d'appels pour loader les objets.
Je ne dis pas que je ferrais une requête avec un orm plus rapide qu'une procstock optimisé pour une fonctionnalité bien précise réalisé par un expert DBA .
je parle juste d'efficacité, de pragmatisme et de productivité et si ces éléments n'était pas les plus essentiel dans l'informatique on serait encore tous à l'assembleur.
Daccord... sujet maintes fois débattu sur DEV.COM....Je crois que nous n'allons pas faire un débat sur les ORM versus le code SQL
L'idéal: de bons développeurs avec de bons DBA...
L'ORM est un plus certains pour la productivité et peu amener de très bon résultats également même si la perte est ineluctable (si c'est bien fait ce n'est pas énorme) et ne sera pas sensible sur 90 % des appli des gestions...
C'est pour cette raison que j'ai demandé une démonstration pour parler pratique.
Plus facilement des choses pour qui serait compliqué pour qui ?
Plus 1 pour toi, je suis vraiment d'accord avec toi sur ce point.
Je voudrais tout de même te rappeler que l'ASSEMBLEUR n'est pas abondonné, certaines routine critiques des logiciels et exigants en terme de perf et de consommation de memoire sont écrites en assembleur.
C'est simplement, que depuis que les mémoires et les CPU sont devenues très très bons marchés que nous pouvons nous amuser avec tout et sur tout.
Répondre avec citation
Partager