Après avoir lu " Qu'est-ce que l'équivalent Java de Linq? ", J'aimerais savoir, est (minuscule) Query intégré par la langue - en d'autres termes, la possibilité d'utiliser une syntaxe concise pour effectuer des requêtes sur des collections d'objet ou des magasins externes - va être le chemin de l'avenir pour la plupart des objectifs généraux Langues? Ou est-ce que LINQ est un morceau de technologie intéressant qui restera confiné aux langues de Microsoft? Quelque chose entre?
EDIT : Je ne connais pas d'autres langues, mais comme je l'apprenant, il semble que Linq n'est ni sans précédent ni unique. Les idées de Linq - Lambdas et les requêtes - sont présentes dans d'autres langues et les idées semblent se propager.
8 Réponses :
Je dirais que la technologie de requête intégrée dans n'importe quelle langue deviendra fondationnelle dans le temps, en particulier étant donné la récente augmentation d'intérêt des langages de programmation fonctionnelle.
Linq est certainement l'une des raisons les plus importantes que je colle personnellement avec .NET, de toute façon - c'est devenu fondamental pour moi personnellement, et je parie que beaucoup de devs se sentent aussi bien.
Disclaimer: Je n'ai jamais utilisé Linq. S'il vous plaît corrigez-moi si je me trompe.
De nombreuses langues ont des constructions qui permettent aux mêmes choses que Linq avec les types de données linguistiques. Apparemment, la caractéristique la plus intéressante est que les constructions LINQ peuvent être converties en SQL, mais ce n'est pas spécifique à LINQ: http://www.aminus.org/blogs/index.php/2008/04/22/linq-in-python?Blog=2 .
Tout comme une clarification, LINQ-TO-SQL et LINQ-TO-entités (les technologies que vous parlez de cela peuvent traduire une expression LINQ en une requête de base de données) sont construites en haut de LINQ. À son noyau, LINQ n'est qu'une manière spécifique à la langue de chaînonner des appels vers des méthodes d'extension sur des interfaces particulières.
De nombreuses langues ont des déclarations sélectionnées, où des clauses? Je ne sais pas de ça beaucoup. Langues orientées de la base de données, oui. Mais celles-ci? Perl? Python? Java, je suppose de la question que j'ai référencée, ne le fait pas. Peux-tu donner quelques exemples?
Python n'a pas Sélectionner des instructions ou où clauses, mais la liste et les compréhensions de générateur font la même chose. Les compréhensions de la liste sont très courantes dans les langues fonctionnelles.
Je pensais que la liste des générateurs et les composants générateurs étaient destinés à créer des listes et des énumérables, ne les consommant pas. Bien que je suppose que Linq est vraiment une sorte de consommation et de les créer ...
D'abord, j'ai entendu parler des complètes de la liste des termes. J'ai regardé sur en.wikipedia.org/wiki/list_compréhension et il semble que les compréhensions de liste sont sélectionnées + où les clauses.
Basé sur ma lecture de cet article de Wikipedia, il semble certain que Linq est une pratique différente des capacités qui ont été réalisées dans différentes langues depuis les années 70. La prochaine question est donc, dans Python (et d'autres langues), puis-je utiliser une compréhension de liste pour définir un ensemble d'instances d'un type anonyme? L'exemple de base que j'ai vu était la sélection d'une fonction de x où x est dans l'ensemble des nombres naturels. Utilisation des mêmes structures de langue, puis-je sélectionner un type anonyme de manière arbitraire complexe?
Que d'autres langues puissent ou non supporter quelque chose comme Linq n'est pas très intéressante tant qu'elles ne le font réellement. MS le rendit réel pour .Net, qui est une grande différence de "ça peut être fait" :-)
@Cheeso: Vous pouvez écrire quelque chose comme ceci, par exemple: [(nom_last_name, p.first_name) pour p chez les personnes] . Cela donnera une liste de tuples (nom de famille, prénom) . c'est ce que tu veux?
@nos: Avez-vous lu le lien dans mon message? Je conviens sur le fait que Linq est plus loin, cependant: il est directement intégré à C # /. Net.
Je ne pense pas que vous puissiez vraiment le classer (ou beaucoup de choses) comme étant soit. Alors que je dirais à peine que Linq est un outil de niche - il possède de nombreuses applications à beaucoup de gens - ce n'est pas "fondamental" imo. Cependant, je ne dirais pas non plus qu'avoir une langue de requérement linq (ou un équivalent) peut être vraiment fondamental à ce stade de la partie. À l'avenir, peut-être, mais pour le moment, vous pouvez créer une requête de différentes manières qui donnent des niveaux de performance variables de manière significative.
Cela semble beaucoup pour moi comme l'enregistrement actif de Ruby, mais je n'ai jamais utilisé Linq. Quelqu'un a utilisé les deux? (J'aurais posté ceci comme un commentaire, mais j'aimerais vraiment être mis à jour sur la réponse - je me trompe probablement, alors ça va être évité :))
(En fait, je devrais dire que AR est comme Linq à SQL, ils n'ont pas mis en œuvre Ar pour d'autres cibles autant que je sache)
Voir, c'est le problème. Je connais Linq mais pas ar. Vous savez Ar mais pas Linq. Essayer de comprendre où ils sont similaires, où ils sont différents, n'est pas si facile. ACH.
AR et Linq sont vraiment orthogonaux et peuvent même être utilisés ensemble. LINQ vous permet d'écrire des déclarations sqlesques directement dans votre langue source, avec la sécurité de type et tout. Ces déclarations sont ensuite interprétées par un fournisseur. Activerecord signifie simplement qu'il existe un mappage de 1-1 entre objets et lignes et chaque objet est responsable de l'épargne. Une requête LINQ peut renvoyer une collection de tels objets.
Enregistrement actif a un système de requête intégré qui se traduit automatiquement entre sa langue maternelle et sa SQL. AR crée également des classes automatiques basées sur des tables de base de données. Donc, sans code du tout, vous pouvez plutôt dire "utilisateur.find (nom =" facture ")" et obtenir une collection d'objets utilisateur avec le nom de champ égal à la facture (la syntaxe est presque certainement fausse puisque je n'ai pas utilisé Ruby pendant quelques années maintenant). Des requêtes beaucoup plus avancées sont également possibles. Le type de sécurité n'est pas pertinent dans Ruby.
Linq ressemble plus à l'ambition que Activerecord. L'ambition est une requête DSL pour Ruby. Vous écrivez vos requêtes dans une langue standardisée et Ambition dispose d'adaptateurs qui traduisent les requêtes pour SQL, LDAP, XQuery, Flickr, vous l'appelez. La différence entre Linq et l'ambition est qu'en raison du pouvoir expressif de Ruby, il n'est pas nécessaire d'attendre que Microsoft apporte à Microsoft de la montagne: l'ambition n'est qu'une bibliothèque de rubis comme une autre. Il étend simplement les méthodes de filtrage déjà existantes sur Enumérables / Array / Hash (Sélectionnez, détectez, rejetez, trouvez, trouvez_tall, tout?, Tout?) À des choses de collection arbitraires.
Après avoir passé des années
Il s'agissait d'une fois que le Time Somone a fait un moyen facile d'accès et de manière intégrée de la langue de parler à une base de données. Linq à SQL aurait dû être fait il y a des années. J'applaudis l'équipe qui la propose - enfin un cadre d'accès à la base de données qui a du sens.
Ce n'est pas parfait, et mes principaux maux de tête en ce moment ne sont pas un support réel pour Linq2SQL pour d'autres bases de données courantes, ni quelque chose comme celui-ci pour Java.
(Linq en général est bien aussi BTW, pas seulement Linq à SQL: -)
Qu'en est-il du cadre d'entité? Il peut supporter tout type de base de données, vous avez juste besoin du fournisseur adéquat
"Fournisseur adéquat" est un problème pour quelques bases de données. Ils n'existent pas, ni ne sont pas encore prêts à la production.
Je pense que les concepts fonctionnels qui sont les sous-marins de Linq deviennent populaires dans de nombreuses langues. Transmettre une séquence d'objets à travers un ensemble de fonctions pour obtenir l'ensemble souhaité d'objets. Essentiellement, en utilisant la syntaxe Lambda sur la syntaxe de la requête.
C'est une manière très puissante et expressive de codage.
Ce n'est pas parce que je pense que c'est une façon fondamentalement meilleure de faire des choses (c'est-à-dire la syntaxe de requête sur la requête). Comparativement, il est beaucoup plus facile d'ajouter le support de bibliothèque sous-jacent aux expressions de requête à une langue que d'ajouter la syntaxe de la requête. Tout ce qui est nécessaire, la syntaxe Lambda pour les requêtes est
La plupart des nouvelles langues prennent en charge Lambdas (même C ++ les obtiennent enfin!). L'ajout du support de la bibliothèque est assez bon marché et peut généralement être effectué par une personne motivée.
Obtenir la syntaxe de la requête dans la langue bien que nécessite beaucoup plus de travail.
Je ne pense pas que Linq soit confiné aux langues de Microsoft, vérifiez-la, il y a déjà quelque chose pour le PHP, vérifiez-le Je pense que Linq est un excellent outil dans le processus de développement et serait personnellement heureux si cela sera transféré dans d'autres langues (comme dans mon exemple de PHP)
Avant Linq, Python avait Expressions génératrices qui sont spécifiques Syntaxe pour effectuer des requêtes sur les collections em>. La syntaxe de Python est plus réduite que celle de Linq, mais laissez-vous essentiellement exécuter les mêmes requêtes que dans Linq. Il y a des mois, j'ai écrit un Blog post comparant des requêtes dans C # et Python , voici un petit exemple:
C # LINQ: P>
orders = ( (c.customer_id, o.order_id)
for c in customers if c.region == 'WA'
for o in c.orders if o.date >= cutoff_date)
Pour énumérer quelques autres caractéristiques similaires: Haskell a une liste de compréhensions (et tout programmeur Python les reconnaîtra probablement immédiatement comme générateurs); Scala a aussi des trucs similaires.
LINQ peut également faire des choses beaucoup plus compliquées que cela