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

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.

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.

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

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.