Was ist der Grund für die Benennung von .NETs Select (Map) und Aggregate (Reduce)?

In anderen Programmiersprachen habe ich Map und Reduce gesehen, und das sind die Eckpfeiler der funktionalen Programmierung. Ich konnte keine Begründung oder Vorgeschichte finden, warum LINQ Aggregate(dasselbe wie Reduce) und Select(dasselbe wie Map) hat.

Warum ich frage, ist, dass ich eine Weile gebraucht habe, um zu verstehen, dass es dasselbe ist, und ich bin gespannt, was der Grund dafür ist.

Dies hängt hauptsächlich mit der Geschichte von LINQ zusammen.

LINQ sollte ursprünglich SQL-ähnlich sein und (weitgehend, aber nicht ausschließlich) zum Herstellen einer Verbindung mit SQL-Datenbanken verwendet werden. Dies führt dazu, dass ein Großteil der Terminologie auf SQL basiert.

So " die Option" kam aus der SQL - selectAnweisung und "Aggregat" kam von SQL - Aggregatfunktionen (zB count, sum, avg, min, max).

Für diejenigen, die in Frage stellen, inwieweit sich LINQ ursprünglich auf SQL bezieht, würde ich (zum Beispiel) auf die Artikel von Microsoft zu Cω verweisen, einer Sprache, die von Microsoft Research entwickelt wurde und in der anscheinend die meisten Grundlagen von LINQ erarbeitet wurden aus, bevor sie zu C # und .NET hinzugefügt wurden.

Betrachten Sie zum Beispiel einen MSDN-Artikel zu Cω , in dem es heißt:

Abfrageoperatoren in Cω

Cω fügt der C # -Sprache zwei große Klassen von Abfrageoperatoren hinzu:
- XPath-basierte Operatoren zum Abfragen der Elementvariablen eines Objekts nach Name oder Typ.
- SQL-basierte Operatoren zur Ausführung komplexer Abfragen, bei denen Daten aus einem oder mehreren Objekten projiziert, gruppiert und zusammengefügt werden.

Zumindest soweit ich weiß, wurden die XPath-basierten Operatoren niemals zu C # hinzugefügt, sodass nur die Operatoren, die dokumentiert wurden (bevor LINQ existierte), direkt auf SQL basierten.

Nun ist es sicher richtig, dass LINQ nicht mit den SQL-basierten Abfrageoperatoren in Cω identisch ist. Insbesondere folgt LINQ den grundlegenden Objekten und Funktionsaufrufen von C # viel genauer als Cω. Cω-Abfragen folgten der SQL-Syntax noch genauer, sodass Sie so etwas schreiben können (wiederum direkt aus dem oben verlinkten Artikel):

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

Und ja, der gleiche Artikel befasst sich speziell mit der Verwendung von SQL-basierten Abfragen zum Abfragen von Daten, die aus tatsächlichen SQL-Datenbanken stammen:

Um eine Verbindung zu einer SQL-Datenbank in Cω herzustellen, muss diese als verwaltete Assembly (dh als .NET-Bibliotheksdatei) verfügbar gemacht werden, auf die die Anwendung dann verweist. Eine relationale Datenbank kann in Visual Studio mit dem Befehlszeilentool "sql2comega.exe" oder dem Dialogfeld " Datenbankschema hinzufügen ... " als verwaltete Assembly für ein Cω verfügbar gemacht werden . Datenbankobjekte werden von Cω verwendet, um die auf dem Server gehostete relationale Datenbank darzustellen. Ein Datenbankobjekt hat eine öffentliche Eigenschaft für jede Tabelle oder Sicht und eine Methode für jede in der Datenbank gefundene Tabellenwertfunktion. Um eine relationale Datenbank abzufragen, muss eine Tabelle, eine Ansicht oder eine Tabellenwertfunktion als Eingabe für einen oder mehrere der SQL-basierten Operatoren angegeben werden.

Das folgende Beispielprogramm und die Ausgabe zeigen einige der Möglichkeiten, SQL-basierte Operatoren zum Abfragen einer relationalen Datenbank in Cω zu verwenden. Die in diesem Beispiel verwendete Datenbank ist die Beispieldatenbank Northwind, die mit Microsoft SQL Server geliefert wird. Der im Beispiel verwendete Namens-DB verweist auf eine globale Instanz eines Datenbankobjekts im Northwind- Namespace der mit sql2comega.exe generierten Northwind.dll- Assembly .

Also, ja, von Anfang an (oder sogar vor Beginn, abhängig von Ihrer Sichtweise) basierte LINQ explizit auf SQL und sollte speziell den Zugriff auf Daten in SQL-Datenbanken ermöglichen.

LINQ-Methoden in .Net

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

wurden so benannt, dass sie mit der LINQ-Abfragesyntax in C # (und VB.NET) übereinstimmen

from x in source
where condition
select projection

Das wurde entwickelt, um Menschen, die sich mit SQL auskennen, vertraut zu sein

SELECT projection
FROM source x
WHERE condition

Select and Aggregate macht für mich mehr Sinn. Da Entity die vorherrschende Methode zum Abfragen und Bearbeiten von Daten in .Net wird, wird Linq immer häufiger von Entwicklern verwendet, die es wahrscheinlich gewohnt sind, mit Daten über SQL zu arbeiten. Daher ist die Verwendung von Wörtern wie "Auswählen" für diese Entwickler sinnvoller, da dies die Schlüsselwörter sind, an die sie gewöhnt sind.