Linq to SQL ne manque-t-il pas le point? Les solutions ORM-mappers (SubSonic, etc.) ne sont-elles pas des solutions sous-optimales?

J’aimerais que la communauté prenne en compte certaines de mes reflections sur Linq pour Sql et les autres mappeurs ORM.

J’aime Linq to Sql et l’idée d’exprimer la logique d’access aux données (ou les opérations CRUD en général) dans votre langue de développement natif, plutôt que d’avoir à faire face à une “incompatibilité d’impédance” entre C # et SQL. Par exemple, pour renvoyer une liste d’instances d’événements compatible avec ObjectDataSource pour une couche de gestion, nous utilisons:

return db.Events.Select(c => new EventData() { EventID = c.EventID, Title = c.Title }) 

Si je devais implémenter cela en utilisant d’anciennes constructions SQL-à-C #, je devrais créer une classe de commande, append le paramètre EventID (en utilisant une chaîne pour décrire l’argument “@EventID”), append la chaîne de requête SQL à la Classe de commande, exécutez la commande, puis utilisez (de type cast) nwReader [“FieldName”] pour extraire chaque valeur de champ renvoyée et l’affecter à un membre d’une instance nouvellement créée de ma classe EventData (yuck).

C’est pourquoi les gens aiment Linq / SubSonic / etc. et je suis d’accord.

Cependant, dans l’ensemble, je vois un certain nombre de choses qui ne vont pas. Mon impression est que Microsoft voit également quelque chose qui ne va pas et c’est pourquoi ils tuent Linq en SQL et essaient de déplacer des personnes vers Linq vers des entités. Seulement, je pense que Microsoft est en train de doubler un mauvais pari.

Alors, qu’est-ce qui ne va pas?

Le problème est qu’il ya des astronautes d’architecture , en particulier chez Microsoft, qui regardent Linq vers SQL et se rendent compte que ce n’est pas un véritable outil de gestion de données: . Vous voyez cela se manifester dans les ambitions derrière Linq to Entities, les articles de blog sur la nature révolutionnaire de Linq et même le défi LinqPad .

Et le problème est que cela suppose que SQL est le problème. Autrement dit, afin de réduire un léger inconfort (incompatibilité d’impédance entre SQL et C #), Microsoft a proposé l’équivalent d’une combinaison spatiale (isolation complète) lorsqu’un pansement (Linq to SQL ou quelque chose de similaire) fonctionnerait parfaitement.

Pour autant que je sache, les développeurs sont assez intelligents pour maîsortingser le modèle relationnel et l’appliquer intelligemment dans leurs efforts de développement. En fait, j’irais plus loin et dirais que Linq to SQL, SubSonic, etc. sont déjà trop complexes: la courbe d’apprentissage n’est pas très différente de la maîsortingse de SQL elle-même. Comme, dans un avenir prévisible, les développeurs doivent maîsortingser le langage SQL et le modèle relationnel, nous devons maintenant apprendre deux langages de requêtes / CRUD. Pire encore, Linq est souvent difficile à tester (vous n’avez pas de fenêtre de requête), nous retire une couche du vrai travail que nous faisons (il génère du SQL), et a un support très maladroit (au mieux) pour les constructions SQL comme Date de traitement (par exemple DateDiff), “Having” et même “Group By”.

Quelle est l’alternative? Personnellement, je n’ai pas besoin d’un modèle différent pour l’access aux données comme Linq to Entities. Je préférerais simplement afficher une fenêtre dans Visual Studio, saisir et valider mon SQL, puis appuyer sur un bouton pour générer ou compléter une classe C # pour encapsuler l’appel. Puisque vous connaissez déjà SQL, ne préférez-vous pas simplement entrer quelque chose comme ceci:

 Select EventID, Title From Events Where Location=@Location 

et se retrouver avec une classe EventData qui contient les champs EventID et Title en tant que propriétés et B) a une méthode de fabrique qui prend une chaîne ‘Location’ en tant qu’argument et génère une liste ? Il faut bien réfléchir au modèle object (l’exemple ci-dessus ne traite évidemment pas de cela) mais l’approche fondamentale consistant à toujours utiliser SQL tout en éliminant la non-concordance d’impédance me plaît beaucoup.

La question est: est-ce que je me trompe? Microsoft doit-il réécrire l’infrastructure SQL pour ne plus avoir à apprendre à gérer les données SQL / relationnelles? Peuvent- ils réécrire l’infrastructure SQL de cette manière? Ou pensez-vous qu’une couche très fine au-dessus de SQL pour éliminer les difficultés de configuration des parameters et d’access aux champs de données est tout à fait suffisante?

Mise à jour Je voulais promouvoir deux liens vers le haut car je pense qu’ils capturent des aspects importants de ce que je suis après. Tout d’abord, CodeMonkey souligne un article intitulé “Le Vietnam de l’informatique”. Cela prend du temps pour commencer mais c’est une lecture très intéressante. Deuxièmement, AnSGri attire l’attention sur l’une des pièces les plus importantes de Joel Spolsky: The Law of Leaky Abstractions . Ce n’est pas exactement sur le sujet mais c’est proche et c’est une bonne lecture.

Mise à jour 2: J’ai donné la “réponse” à ocdecio bien qu’il y ait beaucoup de bonnes réponses ici et que le choix de la “bonne” réponse soit purement subjectif. Dans ce cas, sa réponse concorde avec ce que j’estime être la meilleure pratique compte tenu de l’état actuel de la technologie. C’est un domaine que je compte bien évoluer, cependant, les choses pourraient bien changer. J’aimerais remercier toutes les personnes qui ont consortingbué, j’ai invité tout le monde à donner une réponse réfléchie.

    Depuis au moins 6 ans, j’utilise mon propre ORM basé sur un concept très simple: la projection. Chaque table est projetée dans une classe et SQL est généré à la volée en fonction de la définition de la classe. Il me faut toujours connaître le langage SQL, mais le CRUD est simple à 90%, et je n’ai jamais eu à gérer de connexions, etc. – et cela fonctionne pour les principaux fournisseurs de bases de données.

    Je suis content de ce que j’ai et je n’ai rien trouvé qui vaille.

    Permettez-moi de commencer en disant que je suis un gars de firebase database teinté dans la laine.

    Comme une généralisation flagrante : les développeurs ne connaissent pas le SQL. Les développeurs ne veulent pas vraiment connaître le SQL. Ils peuvent l’écrire, ils peuvent concevoir des tables, mais cela les rend mal à l’aise. Ils ont tendance à faire des choses stupides quand la requête nécessaire est plus qu’une simple jointure. Pas parce que les développeurs sont stupides – car ils ne peuvent pas être dérangés. Ils aiment vivre dans un monde où ils ne doivent gérer qu’un seul espace de concept; Passer des objects aux tableaux et revenir est un contexte qui change le prix pour lequel ils n’aiment pas payer.

    Cela ne signifie pas qu’ils sont mauvais ou mauvais; cela signifie qu’il y a une possibilité d’amélioration. Si vos clients (dans ce cas, les développeurs utilisant votre framework) n’aiment pas SQL et les tables, donnez-leur une couche d’abstraction leur permettant de s’en sortir sans avoir à gérer le désordre sous-jacent.

    C’est la même logique qui fait de la récupération de la mémoire / gestion de la mémoire automatisée un grand succès. Oui, les développeurs peuvent y faire face. oui, ils peuvent écrire du code mieux optimisé sans cela; mais ne pas avoir à les gérer les rend plus heureux et plus productifs.

    Je pense que la popularité des ORM a été engendrée par les développeurs développant des couches de données et écrivant le même code CRUD encore et encore, application après application. Les ORM ne sont qu’un autre outil / technologie qui permet aux développeurs de consacrer moins de temps à l’écriture des mêmes instructions SQL et à se concentrer sur la logique de l’application (espérons-le).

    À mon humble avis, OR / M ne consiste pas seulement à «extraire le SQL» ou à cacher le SQL, ou à activer le support multi-SGBD.

    Il vous permet de vous concentrer davantage sur votre domaine problématique, car vous devez passer moins de temps à écrire les requêtes SQL CRUD ennuyeuses. D’un autre côté, si vous utilisez un bon OU / M, cet OU / M devrait vous permettre d’écrire des requêtes SQL si cela semble être nécessaire.

    Un OR / M peut être un outil puissant si vous l’utilisez correctement; il peut prendre en charge le chargement paresseux, les requêtes polymorphes / associatons …
    Ne vous méprenez pas Il n’y a rien de mal avec le SQL simple, mais si vous devez prendre soin de traduire votre modèle relationnel (bien pensé et normalisé) en un modèle OO / domaine expressif, je pense que vous passez beaucoup de temps à faire de la plomberie.

    Utiliser un OR / M ne signifie pas non plus que vous, en tant que développeur, ne devez pas connaître SQL. Le contraire est vrai à mon humble avis.
    Connaître SQL et savoir écrire une requête SQL efficace vous permettra d’utiliser correctement un OR / M.

    Je dois également admettre que j’écris ceci en pensant à NHibernate. C’est le OU / M que j’utilise avec atm, et je n’ai pas encore utilisé Linq to SQL ou Linq pour les entités.

    Le design de Linq et le framework linq to entity ont certainement une utilité en tant qu’outil orm, mais la grande idée est qu’il sera utilisé comme une API commune pour interroger TOUTES les sources de données, pas seulement les SGBDR.

    Je me souviens avoir lu que linq, bien que visiblement conçu avec SQL en tête, est censé être un langage de requête pour tout magasin de données. Vous pouvez écrire des requêtes linq pour SQL, mais vous pouvez également écrire théoriquement des requêtes linq qui ciblent ldap, les systèmes de fichiers, Exchange, les services Web, à l’infini. Vous ne pouvez pas utiliser SQL pour ces programmes.

    Vous devez également apprendre une API différente pour presque chaque magasin de données. Linq donne à chacun une cible commune pour créer une API d’access aux données.

    Que cette vision fonctionne ou non rest à voir, mais c’est l’idée. Je pense que, comme nous voulons que les systèmes interagissent de plus en plus, nous pourrions trouver de très bons usages pour l2e.

    Je vais append quelques références si je peux les retrouver.

    http://laribee.com/blog/2007/03/17/linq-to-entities-vs-nhibernate/

    Vous devez cesser de vous inquiéter et apprendre à aimer l’ORM. De telles abstractions nous aideront à concentrer nos compétences et à faire des progrès dans le domaine.

    Il rest encore beaucoup à faire pour tirer parti des compétences fonctionnelles acquises et les appliquer dans la couche applicative. C’est en fait l’une des forces de LINQ to SQL par rapport aux autres ORM.

    Je ne peux qu’être d’accord avec beaucoup d’autres commentaires. Le temps que vous économisez, vous pouvez vous concentrer sur le raffinement de votre modèle de domaine et améliorer l’application. Et, une fois que vous avez identifié le goulot d’étranglement, utilisez pour créer un SQL optimisé.

    Ce qui n’est pas forcément évident, c’est que l’ORM comporte un certain nombre de fonctionnalités vraiment intéressantes. La carte d’identité qui évite de charger des éléments encore et encore, le chargement différé vous aide à exprimer le domaine avec moins de plomberie et l’unité de travail vous aide à suivre les modifications et à optimiser les écritures de firebase database.

    Je suis d’accord à 100%. Cela tient en grande partie au fait que les compétences de codage procédural et les compétences de codage SQL sont très différentes. et ce fait n’est pas largement reconnu. Ainsi, jusqu’à ce que cette réalisation se concrétise, les programmeurs recherchent des moyens de rendre leurs compétences transférables d’un domaine à l’autre.

    Ça ne marche pas

    Vous devez simplement apprendre à déphaser: apprenez comment penser différemment votre code en fonction du domaine auquel vous vous adressez.

    Quelqu’un d’autre a-t-il remarqué à quel point une requête devient plus complexe et plus verbeuse lorsqu’elle est mappée de SQL vers LINQ? Comme dans tous les exemples en ligne?

    Comme Dmisortingy l’a souligné , les développeurs ne connaissent pas le langage SQL. Plus précisément, la majorité connaît le SQL, mais ne le comprend pas et n’aime certainement pas, alors ils ont tendance à rechercher la solution miracle, créant la demande pour des choses comme Linq pour créer l’illusion (hm, abstraction) n’utilisez rien de différent de leurs classes bien-aimées.

    C’est très mauvais, car la loi des abstractions qui fuient est toujours vraie.

    Certaines solutions ORM sont particulièrement efficaces (JPA / Hibernate, par exemple), non pas parce que vous n’avez pas à vous soucier de SQL. En fait, pour utiliser JPA efficacement, vous avez besoin d’une compréhension très approfondie de la firebase database en général, en particulier des capacités d’interrogation. Le bon point est que la machine fait le travail ennuyeux , au point où elle génère automatiquement toute la firebase database à partir de zéro.

    Linq to SQL, comme je pense, ne résout pas le problème réel. C’est une sorte de présentation, rien de plus. Cela peut être bien, même si cela complique le langage déjà complexe. D’autre part, Linq to Objects est un concept très intéressant, car il est en quelque sorte une requête SQL pour les collections.

    Perspective historique.

    Quand Codd et. Al. À l’origine, ils élaboraient la théorie et la mise en œuvre de bases de données relationnelles. Une question entièrement distincte était «Comment interrogeons-nous ces choses»? Un certain nombre de stratégies et de syntaxes ont été proposées, avec diverses forces et faiblesses. Un de ces candidats était SQL (dans sa forme la plus ancienne, évidemment.) Un autre était QBE (Query By Example). Un autre s’appelait “quel”, je crois; et il y en avait plusieurs autres. SQL n’est certainement pas devenu dominant car il a été salué comme supérieur à tous les autres. Malheureusement, les autres ont pratiquement disparu, à la pauvreté de tous (car ils pouvaient être utilisés simultanément sur les mêmes données).

    Si Microsoft a une bonne histoire de faire revivre l’une de ces autres langues ou d’avoir inventé un ajout intéressant, alors je pense que nous serions bien avisés d’écouter. Mais jusqu’à présent, tout ce que j’ai vu est encore un “Un Anneau pour les gouverner tous”.

    Il y a énormément de reflection et de rigueur derrière SQL, et une durabilité éprouvée. Microsoft a une certaine histoire de croire que son organisation de développement, certes de haut niveau, peut surpasser le rest d’entre nous, y compris nos mémoires institutionnelles collectives. Cela ne semble pas souvent fonctionner de cette façon. Tant que nous sums liés aux banques de données relationnelles, nous devons réfléchir à deux fois aux paradigmes d’abstraction des supersets qui nous éloignent du métal nu avec des promesses de performances égales ou meilleures.

    Étant moi-même l’auteur d’un projet ORM, je dois admettre que ma réponse à une question comme celle-ci risque d’être un peu biaisée. J’ai déjà développé certaines de mes reflections sur la réponse avant de lire la question, alors je suis déjà un peu ancré.

    Je dirai que la raison pour laquelle j’ai développé un ORM n’était pas due à la “non-concordance d’impédance” entre SQL et la programmation impérative, mais plutôt uniquement pour devenir une firebase database indépendante de la plateforme. L’ancien problème de devoir écrire plus de code pour gérer la persistance est un petit problème facile à résoudre si vous travaillez avec un seul fournisseur de firebase database. Devenir indépendant de la plateforme de firebase database est un problème beaucoup plus complexe et imo a un impact beaucoup plus important sur la rentabilité de votre entreprise en supposant que, comme moi, vous envisagez de vendre des logiciels à d’autres personnes.

    Lorsque j’ai commencé à travailler sur mes outils ORM il y a plusieurs années, le concept n’était pas pratique dans la langue de mon choix, la plupart des gens à qui je parlais ne comprenaient pas pourquoi je travaillais et certaines voix respectées de la communauté dans des revues spécialisées déclarant que ce que j’avais déjà fait était non seulement impossible mais aussi indésirable. Certaines des mêmes raisons ont été données – c’est trop complexe, c’est limitatif et cela ajoute des frais supplémentaires. Aujourd’hui, la même communauté a au moins trois outils d’abstraction de firebase database populaires (bien qu’il y ait un débat sur la définition du terme ORM). La raison pour laquelle je mentionne cela est que lorsque j’ai commencé à travailler sur ces outils, les objections initiales avaient beaucoup plus de poids que maintenant. La technologie sous-jacente, à la fois matérielle et logicielle, a évolué au fil des années pour rendre ces outils beaucoup plus pratiques à long terme. Ma tendance est d’essayer de prendre un logiciel à long terme et de travailler sur des solutions qui ne sont peut-être pas encore très pratiques mais qui deviendront bientôt pratiques. Donc, étant donné que je ne considérerais pas LINQ to Entities comme une bonne solution pour certains problèmes.

    J’ai aussi tendance à préférer plus d’options plutôt que moins. Donc, même si je soutiens l’idée de développer LINQ to Entities, je suis moins enclin à prendre en charge la suppression de LINQ to SQL simplement parce que LINQ to Entities est devenu disponible. Les objects sont parfaits pour faire ce que font les objects, cela ne fait aucun doute … Dans mon opinion (encore biaisée), un problème survient lorsque les gens voient un outil ou un paradigme logiciel comme une “solution magique” et veulent insister pour que tout doit être comme ça. Il est bien connu qu’une firebase database relationnelle est très efficace pour gérer certaines autres tâches, le reporting étant un bon exemple. Donc, à mon avis, c’est un peu comme se tirer une balle dans le pied pour insister sur le fait que tout doit être une entité, car alors vous vous forcez à utiliser un outil inefficace pour le travail. Donc en ce qui concerne le reporting en particulier, me débarrasser de LINQ to SQL et utiliser uniquement LINQ to Entities au moins en surface me semble être le modèle anti- inversion d’abstraction .

    Donc je suppose que le synopsis de ma réponse est le suivant: utilisez un marteau si votre problème est un clou – utilisez un tournevis si votre problème est une vis.

    La déclaration de Dmitry selon laquelle les développeurs n’aiment pas SQL peut avoir beaucoup de vérité, mais la solution n’est pas seulement ORM. La solution consiste à embaucher dans le cadre de l’équipe de développement un DBA de développement. Dans mon entreprise, mon équipe de développement .net possède un excellent administrateur de firebase database Oracle qui ne fait absolument aucun travail de production. Son rôle dans notre équipe est la modélisation des données, la conception physique de la firebase database, la création de procédures stockées, l’parsing des données, etc. Tous nos access à la firebase database se font via des procédures stockées.

    Qu’est-ce qu’un DBA de développement? http://www.simple-talk.com/sql/database-administration/what-use-is-a-development-dba/

    Je pense que la logique derrière ces choses est que la création et l’exécution d’une instruction SQL dans la couche Framework est insignifiante par rapport à la surcharge dans d’autres parties du système (par exemple, un aller-retour HTTP est beaucoup plus long).

    Les avantages – un développement rapide, des requêtes qui s’intègrent dans la langue plutôt que des chaînes échappées, etc. – l’emportent souvent sur les inconvénients. Si les performances posent problème, vous pouvez les optimiser ultérieurement.

    Je ne pense pas que “ne pas avoir besoin de connaître SQL” est un facteur. Tout développeur décent devra connaître le SQL à un moment de son développement. L’idée d’une couche d’abstraction de firebase database consiste à supprimer l’effort de génération de code passe-partout pour les requêtes de firebase database.

    En effet, dans notre système en Java, j’ai créé un utilitaire de génération de code qui prenait des classes annotées et générait une API CRUD complète, et traitait toutes les choses bizarres que vous repreniez au fil du temps. Il est beaucoup plus facile de créer votre modèle et de l’annoter que d’écrire un DAO. Mettez à niveau un tel outil et vous obtenez LINQ ou Hibernate ou une myriade d’autres solutions DB ORM.

    Je fais de la programmation d’applications de bases de données et d’applications dissortingbuées (Web et compilées) et je pense que prendre le temps de développer des couches d’access aux données basées sur des procédures stockées est un bon investissement. Personnellement, je préfère faire de la modélisation des données et identifier les processus nécessaires au début du processus de développement … semble aider à découvrir les problèmes de structure / logique de conception / interface.

    Je ne suis pas un grand fan de la programmation de firebase database en ligne (que le code SQL soit généré manuellement ou par machine). Je crois que la firebase database est le fondement de votre application et que le temps de le coder manuellement est utile.

    Cela dit, le concept OODBMS m’insortinggue et j’espère qu’un jour je pourrai en travailler dans un environnement de production.

    Si vous souhaitez qu’une firebase database fonctionne à mesure qu’elle évolue, elle doit être conçue et normalisée en fonction des meilleures pratiques du modèle relationnel de firebase database.

    Si vous laissez le modèle object et l’ORM dicter votre modèle de données, vous vous retrouverez avec un modèle de données médiocre qui n’est pas normalisé et / ou contient des artefacts du modèle d’object.

    1 table = 1 classe est une mauvaise idée.

    Pour commencer, vous n’avez jamais, jamais, de classes qui représentent des tables de liens plusieurs-à-plusieurs ou plusieurs-à-un. Celles-ci correspondent à des collections enfants dans le modèle d’object – les liens eux-mêmes ne sont pas des objects.

    Si vous traitez votre firebase database comme des tables pour simplement conserver vos objects en ligne (une approche commune) et donner à l’application un access direct aux tables, vous renoncez à la définition d’une couche d’interface de services de firebase database son périmètre.

    Les ORM ont leur place, mais si vous les utilisez pour simplement conserver vos objects tels que conçus dans votre modèle d’object, votre firebase database ne sera pas une firebase database relationnelle, et elle ne pourra pas être utilisée comme firebase database, refactoring, etc.

    Il y avait une autre question ici qui portait sur les ORM en général. Jetez-y un coup d’œil pour savoir si l’inadéquation de l’impédance est une affaire aussi importante que cela.

    Je pense que la vraie solution dont ils avaient besoin était quelque chose de plus littéral que SQL. VB.Net 9.0 prend en charge les littéraux XML , qui vous permettent d’écrire du code XML directement dans votre code, et de vous assurer qu’il est validé et conforme à la DTD. Une fonctionnalité similaire serait les littéraux SQL qui vous permettent d’écrire du code SQL en ligne dans votre code .Net et de le faire valider par l’EDI. Il faudrait une sorte d’architecture de plugin pour vérifier les informations par rapport à la firebase database, mais cela pourrait être facilement écrit pour les moteurs de bases de données populaires. Cela fournirait ce que je pense être la vraie solution, au problème qu’ils essayaient de résoudre, sans avoir recours à des solutions sous-optimales.

    Codemonkey fait un très bon point: les procédures stockées offrent un niveau d’abstraction qui répond à certaines des promesses des modèles ORM plus complexes. Ce n’est pas intuitif à première vue, mais je peux penser à un exemple directement à partir de mon propre code. J’ai un sproc “check-in” qui touche près d’une douzaine de tables (à qui appartient cet identifiant? Est-ce qu’ils ont un abonnement? Y a-t-il des messages? Ont-ils des points pour cet enregistrement? Etc.).

    Modeling this in C# – no matter how sophisticated the data model – would never be a good idea as it would necessitate many sortingps “over the wire” to check on data and update various tables. While it is true that you can handle sprocs in Linq or other ORMS, all I need is a wrapper class that allows me to call the sproc with standard C# parameters. In fact, this was such a pressing need for me that I wrote a code generator in T-SQL to create such wrappers.

    I don’t like any of the current solutions – but i prefer more choices over less choices 😉

    i used an OODBMS in a project long ago that was the closest to getting it right (unfortunatley the product had some heinous bugs and terrible tech support) – object persistence was largely invisible , handled behind the scenes (via preprocessor code-generator) and controlled by very simple Update, Delete, and Find methods and simple containers.

    I’d love to see this (and perhaps some object-entity model does this well already) again, with OCL (Object Constraint Language) as the native multi-object query language

    I have to agree that the outburst of ORM tools largely stems from the annoyance of writing SQL, dealing with whatever DB driver you have to use, internally abstracting between DBs (Oracle vs SQL Server, vs whatever for code reusability), and transforming data types.

    Ideal solution? definately not! However, I think this is an iteration in the process of better merging the application with the data store. After all, in most cases, having a DB without an accessing application written in whatever language is practically useless. (would you really ever just install oracle, and expect all employees to work in SQLPlus directly?)

    As such, I think the data store and the application are just moving together in a way that the application developer can more easilly interact with the data store.

    For .NET in particular, what I’d much rather see instead of Linq is a built in way to map a class definition to an underlying data source to an underlying data store, and have all the plumbing just work.

    In other words I could just say “Employee.Name = ‘rally25rs’;” and the object’s property would change, and underneath that it would persist to the data store itself. Just ditch SQL completely instead of going 1/2 way like Linq to SQL does now.

    Of course, a solution like that brings up issues with performance, transaction handling, etc.

    Maybe the entire concept of programming language and relational database need to be rethought and realigned? At their core, they are completely separate and disjointed entities. Maybe its time to just ditch the “relational sql aware database” and build the next thing, whee executing a line of code would directly operate on the database.

    there´s no problem with linq, but with those who use it and ignore what happens “behind the scenes”

    I still prefer to get my hands dirty with SQL. At least i´ll know exatcly whats happening.

    Ted Neward wrote a great essay on his take on this subject – that ORM’s are the “Vietnam” of computer science…

    http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx

    Most people have missed an essential point: in most cases, you are significantly more productive when querying in LINQ than in SQL. I’ve written an article on why this is so.

    When I set the LINQPad Challenge, I wasn’t joking: I do nearly all of my ad-hoc querying in LINQ because most queries can be written more quickly and reliably in LINQ than in SQL. I’ve also designed and worked on large business applications using LINQ to SQL and seen a major gains in productivity. This is not “architecture astronaut” stuff – LINQ to SQL is a productive and practical technology that drives this very site .

    The biggest hindrance with LINQ is failing to properly learn it. I’ve seen so many LINQ queries that are horrible transliterations of SQL queries to back this up. If you write LINQ queries using only your knowledge of SQL, the end result can only be the same – or worse – than SQL.

    I just discovered this question. I guess it’s pretty much played out by now, but I’m going to throw in my two cents anyway…

    I only want to write code for the things that aren’t obvious.

    CRUD code is obvious. I don’t want to write it. Therefore, ORMs are a good idea.

    This doesn’t mean that ORMs don’t have problems, but the problems are with execution, not intent. As ORMs mature, the problems will diminish, and the productivity gains already available for simple scenarios will eventually extend to complex scenarios as well.

    LINQ is also a good idea. Others have mentioned a number of the advantages, but all I have to do is think about the first time I sortinged to do a pivot in LINQ where I didn’t know the number of columns in advance. Or the first time I realized I didn’t have to create a new DataView every time I wanted to sort or filter something. LINQ empowers me to do everything I want to do with data in C#, rather than having to figure out how divide up the work between SQL and C#.

    So, yes, ORMs, LINQ, and other emerging technologies are suboptimal solutions, but they don’t miss the point, and they won’t be suboptimal forever.

    I wanted to write this as a reply to @SquareCog reply here , but it told me I had -1836 characters left. SO noob here so apologies if I’ve done this wrong.


    In the 18th century gentleman of leisure used to study science. At that time science in its entirety was not such a large subject that a reasonably intelligent person couldn’t understand it all. By which I mean a single learned fellow could understand the entirety of scientific thinking of the time.

    As time has gone by hundreds of new fields of science have been discovered and each one researched to the point where these days very few people can even understand the entirety of a single complete field of science.

    So it is with programming.

    These days the programming language field is large enough and growing fast enough that it is as much as can be reasonably be expected of a developer to know the entirety of his own specialised languages(s). For a skilled coder to also be expected to understand the entirety of the database field too, including database design, the nuances of native SQL and how it operates on different databases and the administration of those databases too, is possibly asking a bit much.

    I think some of the responders here are glossing over some of the complexities of developing a large performant enterprise level database, knowing a ‘handful of SQL statements’ most certainly does not cut it. Which is why most large software houses have dedicated teams of database developers. As Stroustrup says, ‘Divide and conquer’ is the only way to effectively deal with the complexity inherent in developing and managing large software projects.

    Developers don’t dislike working with SQL because they are lazy or because it makes them feel ‘icky’. They dislike working with SQL because they are smart. They know better than anyone that only someone who specialises in SQL will deliver the highest quality database functionality and that for them to be put into the position of being ‘jack of all trades’ developers is a suboptimal development strategy.