Quel est le raisonnement derrière la dénomination des .NETs Select (Map) et Aggregate (Reduce)?


17

Dans d'autres langages de programmation, j'ai vu Map and Reduce, et ce sont les pierres angulaires de la programmation fonctionnelle. Je n'ai trouvé aucun raisonnement ou historique pour lesquels LINQ a Aggregate(identique à Reduce) et Select(identique à Map)?

Pourquoi je demande, c'est qu'il m'a fallu un certain temps pour comprendre que c'est la même chose et je suis curieux de savoir pourquoi.




Pour ma part, j'aimerais connaître le raisonnement qui sous-tend la sélection de noms "Map" et l'agrégation "Reduce" pour commencer.
Den

Réponses:


32

Cela se résume principalement à l'histoire de LINQ.

LINQ était à l' origine destiné à être de type SQL et utilisé (en grande partie, mais pas exclusivement) pour se connecter à des bases de données SQL. Cela conduit à une grande partie de sa terminologie basée sur SQL.

Alors, « sélectionner » est venu de la SQL selectdéclaration, et « agrégat » provenaient de fonctions SQL globales (par exemple count, sum,avg , min, max).

Pour ceux qui se demandent dans quelle mesure LINQ était à l'origine lié à SQL, je ferais référence (par exemple) aux articles de Microsoft sur Cω, qui a été un langage conçu par Microsoft Research, et semble être l'endroit où la plupart des bases de LINQ ont été travaillées avant d'être ajoutés à C # et .NET.

Par exemple, considérez un article MSDN sur Cω , qui dit:

Opérateurs de requête en Cω

Cω ajoute deux grandes classes d'opérateurs de requête au langage C #:
- Les opérateurs basés sur XPath pour interroger les variables membres d'un objet par nom ou par type.
- Opérateurs basés sur SQL pour effectuer des requêtes sophistiquées impliquant la projection, le regroupement et la jonction de données à partir d'un ou plusieurs objets.

Pour autant que je sache, les opérateurs basés sur XPath n'ont jamais été ajoutés à C #, ne laissant que les opérateurs qui ont été documentés (avant que LINQ existe) comme étant basés directement sur SQL.

Maintenant, il est certainement vrai que LINQ n'est pas identique aux opérateurs de requête basés sur SQL en Cω. En particulier, LINQ suit les objets de base de C # et la syntaxe des appels de fonction beaucoup plus étroitement que Cω. Les requêtes Cω suivaient la syntaxe SQL de plus près, vous pouvez donc écrire quelque chose comme ça (encore une fois, tiré directement de l'article lié ci-dessus):

 rows = select c.ContactName, o.ShippedDate
      from c in DB.Customers
      inner join o in DB.Orders
      on c.CustomerID == o.CustomerID;

Et oui, le même article parle spécifiquement de l'utilisation des requêtes basées sur SQL pour interroger des données provenant de bases de données SQL réelles:

Pour se connecter à une base de données SQL en Cω, elle doit être exposée en tant qu'assembly managé (c'est-à-dire un fichier de bibliothèque .NET), qui est ensuite référencé par l'application. Une base de données relationnelle peut être exposée à un Cω en tant qu'assembly managé à l'aide de l' outil de ligne de commande sql2comega.exe ou de la boîte de dialogue Ajouter un schéma de base de données ... à partir de Visual Studio. Les objets de base de données sont utilisés par Cω pour représenter la base de données relationnelle hébergée par le serveur. Un objet Database a une propriété publique pour chaque table ou vue et une méthode pour chaque fonction table trouvée dans la base de données. Pour interroger une base de données relationnelle, une table, une vue ou une fonction table doit être spécifiée comme entrée pour le ou les opérateurs SQL.

L'exemple de programme et la sortie suivants présentent certaines des capacités d'utilisation des opérateurs basés sur SQL pour interroger une base de données relationnelle en Cω. La base de données utilisée dans cet exemple est l'exemple de base de données Northwind fourni avec Microsoft SQL Server. Le nom de base de données utilisé dans l'exemple fait référence à une instance globale d'un objet Database dans l' espace de noms Northwind de l' assembly Northwind.dll généré à l'aide de sql2comega.exe .

Donc, oui, dès le début (ou même avant le début, selon votre point de vue) LINQ était explicitement basé sur SQL et destiné spécifiquement à permettre l'accès aux données dans les bases de données SQL.


5
Je ne suis pas d'accord que LINQ a été inventé pour les requêtes SQL. LINQ est basé sur les opérations de requête en , qui à leur tour les ont héritées de X♯, qui est basé sur un vieux papier Haskell. Notez que l'un des auteurs desdits documents Haskell est Erik Meijer, qui a également été impliqué dans la conception de X♯ et Cω après cela, et est bien sûr le concepteur de LINQ. Et il était clair dès le début que LINQ pouvait être utilisé pour interroger toutes sortes de choses, pas seulement SQL (il était livré avec LINQ-to-SQL, LINQ-to-XML et LINQ-to-Objects dès le premier jour, sous peu suivi de…
Jörg W Mittag

4
LINQ-to-Entities), et en fait bien plus que des requêtes (c'est essentiellement la syntaxe générale de la compréhension de la monade ). Il a été conçu pour être familier aux programmeurs SQL (et XQuery), mais certainement pas limité à cela. Dans la même veine, les compréhensions de monade de Scala ressemblent à des forboucles, et à Haskell ressemblent à des blocs de code impératifs de style C, et donc Scala appelle son fonctionnement monadique flatMap, et Haskell l'appelle returnpour la même raison: pour s'adapter à l '«illusion» empêchée de (anciens) programmeurs impératifs.
Jörg W Mittag

2
@ JörgWMittag: Voir la réponse modifiée. Je crois que la documentation de Microsoft prend en charge mes déclarations.
Jerry Coffin

3
+1 pour justifier réellement la réponse au lieu de deviner à la légère. Vous ne pouvez pas obtenir une source beaucoup plus fiable que Microsoft lui-même.
milleniumbug

Merci, bien monsieur! C'est exactement le genre de réponse que j'espérais recevoir.
Tx3

8

Méthodes LINQ dans .Net

source.Where(x => condition)
      .Select(x => projection)

ont été nommés pour être cohérents avec la syntaxe de requête LINQ en C # (et VB.NET)

from x in source
where condition
select projection

qui a été conçu pour être familier aux personnes qui connaissent SQL

SELECT projection
FROM source x
WHERE condition

2

Pour moi, Select et Aggregate ont plus de sens. Alors que l'entité devient la méthode dominante pour interroger et manipuler des données dans .Net, Linq est de plus en plus utilisé par les développeurs qui sont probablement habitués à travailler avec des données via SQL. Donc, utiliser des mots comme "Select" a plus de sens pour ces développeurs, car ce sont les mots-clés auxquels ils sont habitués.


4
"de plus en plus de développeurs qui sont probablement habitués à travailler avec des données via SQL" J'en doute. Le gars avec qui je travaille et qui fait l'éloge d'Entity Framework n'a pas pu comprendre qu'il devait faire un seul INNER JOINjour où Entity Framework n'était pas une option. Probablement tout le contraire. De plus en plus de personnes utilisent LINQ tous les jours et évitent activement d' écrire SQL. Les gens qui sont à l'aise avec SQL font probablement plus en SQL.
jpmc26

1
Ce n'est pas ce que j'ai vu. Ce que je trouve principalement (grâce à ma récente recherche d'emploi), c'est que les développeurs qui ont déjà travaillé avec des données à l'aide de procédures stockées commencent à effectuer tous leurs scripts dans le contrôleur. Pour moi, cela aide que Linq utilise des expressions familières. Je ne doute pas que ce soit le cas pour "le gars avec qui vous travaillez", mais ce n'est pas mon expérience.
Christine
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.