Qual è il ragionamento alla base della denominazione di .NET Select (Map) e Aggregate (Reduce)?

Ciò dipende principalmente dalla cronologia di LINQ.

LINQ era originariamente destinato ad essere simile a SQL e utilizzato (in gran parte, sebbene non esclusivamente) per connettersi ai database SQL. Ciò porta a gran parte della sua terminologia basata su SQL.

Quindi, "select" veniva dall'istruzione SQL select e "aggregate" proveniva dalle funzioni di aggregazione SQL (ad esempio count , sum , avg , min , max ).

Per coloro che mettono in dubbio il grado di LINQ originariamente correlato a SQL, mi riferisco (per esempio) agli articoli di Microsoft su Cω, che era un linguaggio ideato da Microsoft Research, e sembra essere la maggior parte delle nozioni di base di LINQ sono stati elaborati prima di essere aggiunti a C # e .NET.

Ad esempio, considera un articolo MSDN su Cω , che dice:

Query Operators in Cω

Cω adds two broad classes of query operators to the C# language:
- XPath-based operators for querying the member variables of an object by name or by type.
- SQL-based operators for performing sophisticated queries involving projection, grouping, and joining of data from one or more objects.

Almeno per quanto ne so, gli operatori basati su XPath non sono mai stati aggiunti a C #, lasciando solo gli operatori che sono stati documentati (prima che LINQ esistesse) come basati direttamente su SQL.

Ora, è certamente vero che LINQ non è identico agli operatori di query basati su SQL in Cω. In particolare, LINQ segue gli oggetti base di C # e la sintassi delle chiamate di funzione molto più strettamente di quanto fatto da Cω. Le query Cω hanno seguito la sintassi SQL ancora più da vicino, quindi è possibile scrivere qualcosa di simile (di nuovo, disegnato direttamente dall'articolo collegato sopra):

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

E sì, lo stesso articolo parla in modo specifico dell'uso delle query basate su SQL per interrogare i dati provenienti da veri e propri database SQL:

To connect to a SQL database in Cω, it must be exposed as a managed assembly (that is, a .NET library file), which is then referenced by the application. A relational database can be exposed to a Cω as a managed assembly either by using the sql2comega.exe command line tool or the Add Database Schema... dialog from within Visual Studio. Database objects are used by Cω to represent the relational database hosted by the server. A Database object has a public property for each table or view, and a method for each table-valued function found in the database. To query a relational database, a table, view, or table-valued function must be specified as input to the one or more of the SQL-based operators.

The following sample program and output shows some of the capabilities of using the SQL-based operators to query a relational database in Cω. The database used in this example is the sample Northwind database that comes with Microsoft SQL Server. The name DB used in the example refers to a global instance of a Database object in the Northwind namespace of the Northwind.dll assembly generated using sql2comega.exe.

Quindi, sì, sin dall'inizio (o anche prima dell'inizio, a seconda del punto di vista) LINQ era esplicitamente basato su SQL e destinato specificamente a consentire l'accesso ai dati nei database SQL.

Metodi LINQ in .Net

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

sono stati denominati per essere coerenti con la sintassi della query LINQ in C # (e VB.NET)

from x in source
where condition
select projection

che è stato progettato per essere familiare alle persone che conoscono SQL

SELECT projection
FROM source x
WHERE condition

Per me, Select e Aggregate ha più senso. Poiché l'entità diventa il metodo dominante per interrogare e manipolare i dati in. Net, Linq viene sempre più utilizzato dagli sviluppatori che sono probabilmente abituati a lavorare con i dati tramite SQL. Quindi, usare parole come "Seleziona" ha più senso per quegli sviluppatori, perché quelle sono le parole chiave a cui sono abituati.