Isso se resume principalmente à história do LINQ.
O LINQ foi originalmente projetado para ser semelhante ao SQL e usado (amplamente, embora não exclusivamente) para conectar-se aos bancos de dados SQL. Isso faz com que grande parte de sua terminologia seja baseada em SQL.
Assim, "select" veio do SQL selectdeclaração, e "agregado" veio de funções agregadas SQL (por exemplo, count, sum, avg, min, max).
Para aqueles que questionam o grau em que o LINQ originalmente se relacionava com o SQL, eu me referiria (por exemplo) aos artigos da Microsoft sobre Cω, que foi uma linguagem criada pela Microsoft Research, e parece ser o local onde a maioria dos conceitos básicos do LINQ foram trabalhados. antes de serem adicionados ao C # e .NET.
Por exemplo, considere um artigo do MSDN sobre Cω , que diz:
Operadores de consulta em Cω
O Cω adiciona duas classes amplas de operadores de consulta à linguagem C #:
- Operadores baseados em XPath para consultar as variáveis de membro de um objeto por nome ou por tipo.
- Operadores baseados em SQL para executar consultas sofisticadas envolvendo projeção, agrupamento e junção de dados de um ou mais objetos.
Pelo menos até onde eu sei, os operadores baseados em XPath nunca foram adicionados ao C #, deixando apenas os operadores documentados (antes da existência do LINQ) como baseados diretamente no SQL.
Agora, certamente é verdade que o LINQ não é idêntico aos operadores de consulta baseados em SQL no Cω. Em particular, o LINQ segue os objetos básicos do C # e a sintaxe das chamadas de função muito mais de perto do que o Cω. As consultas Cω seguiram a sintaxe SQL ainda mais de perto, para que você pudesse escrever algo assim (novamente, extraído diretamente do artigo vinculado acima):
rows = select c.ContactName, o.ShippedDate
from c in DB.Customers
inner join o in DB.Orders
on c.CustomerID == o.CustomerID;
E sim, o mesmo artigo fala especificamente sobre o uso de consultas baseadas em SQL para consultar dados provenientes de bancos de dados SQL reais:
Para conectar-se a um banco de dados SQL em Cω, ele deve ser exposto como um assembly gerenciado (ou seja, um arquivo de biblioteca .NET), que é referenciado pelo aplicativo. Um banco de dados relacional pode ser exposto a um Cω como um assembly gerenciado usando a ferramenta de linha de comando sql2comega.exe ou a caixa de diálogo Adicionar esquema do banco de dados ... no Visual Studio. Os objetos de banco de dados são usados por Cω para representar o banco de dados relacional hospedado pelo servidor. Um objeto Database possui uma propriedade pública para cada tabela ou exibição, e um método para cada função com valor de tabela encontrada no banco de dados. Para consultar um banco de dados relacional, uma tabela, exibição ou função com valor de tabela deve ser especificada como entrada para um ou mais operadores baseados em SQL.
O seguinte exemplo de programa e saída mostra alguns dos recursos do uso de operadores baseados em SQL para consultar um banco de dados relacional em Cω. O banco de dados usado neste exemplo é o banco de dados Northwind de exemplo que acompanha o Microsoft SQL Server. O DB nome utilizado no exemplo refere-se a uma instância global de um objecto de dados no Adamastor espaço de nomes do Northwind.dll conjunto gerado usando sql2comega.exe .
Portanto, sim, desde o início (ou mesmo antes do início, dependendo do seu ponto de vista), o LINQ era explicitamente baseado em SQL e pretendia especificamente permitir o acesso a dados em bancos de dados SQL.