.NET Seçimi (Harita) ve Toplama (Azaltma) adlarının arkasında yatan neden nedir?

Diğer programlama dillerinde, Harita ve Küçült'ü gördüm ve bunlar fonksiyonel programlamanın temel taşlarıdır. Neden LINQ Aggregate(aynı Reduce) ve Select(aynı ) var herhangi bir neden veya tarih bulamadım Map?

Neden soruyorum, bunun aynı şey olduğunu anlamam biraz zaman aldı ve bunun nedeninin ne olduğunu merak ediyorum.

Bu çoğunlukla LINQ tarihine dayanıyor.

LINQ başlangıçta SQL benzeri olacaktı ve SQL veritabanlarına bağlanmak için (büyük ölçüde olmasa da) kullanıldı. Bu, terminolojisinin çoğunun SQL tabanlı olmasına yol açar.

Yani, "select" SQL gelen selectaçıklamada, ve "agrega" SQL toplam işlevleri geldi (örn count, sum, avg, min, max).

LINQ'nun başlangıçta SQL ile ne derece ilişkili olduğunu sorgulayanlar için, Microsoft Araştırma tarafından tasarlanan bir dil olan ve LINQ ile ilgili temel bilgilerin çoğunun çalıştığı gibi görünen Microsoft'un Cω ile ilgili makalelerine atıfta bulunacağım. C # ve .NET'e eklenmeden önce.

Örneğin, Cω hakkında şöyle bir MSDN makalesi düşünün :

Sorgu İşleçleri Cω

Cω, C # diline iki geniş sorgu işleç sınıfı ekler:
- Bir nesnenin üye değişkenlerini ada veya türe göre sorgulamak için XPath tabanlı işleçler.
- Bir veya daha fazla nesneden gelen verilerin projeksiyonu, gruplandırılması ve birleştirilmesi gibi karmaşık sorgular gerçekleştirmek için SQL tabanlı operatörler.

En azından bildiğim kadarıyla, XPath tabanlı işleçler hiçbir zaman C # 'a eklenmedi, sadece (LINQ var olmadan önce) doğrudan SQL tabanlı olarak belgelenen işleçler kaldı.

Şimdi, LINQ'nun Cω'deki SQL tabanlı sorgu operatörleri ile aynı olmadığı kesinlikle doğrudur. Özellikle LINQ, C # 'ın temel nesnelerini ve işlev çağrıları sözdizimini Cω'den çok daha yakından takip eder. Cω sorguları SQL sözdizimini daha da yakından takip etti, böylece böyle bir şey yazabilirsiniz (yine, doğrudan bağlantılı makaleden alınmıştır):

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

Ve evet, aynı makale özellikle gerçek SQL veritabanlarından gelen verileri sorgulamak için SQL tabanlı sorguları kullanma hakkında konuşuyor:

Cω'de bir SQL veritabanına bağlanmak için, daha sonra uygulama tarafından başvurulan yönetilen bir derleme (yani bir .NET kitaplık dosyası) olarak gösterilmelidir. İlişkisel veritabanı, Visual Studio içinden sql2comega.exe komut satırı aracı veya Veritabanı Şeması Ekle ... iletişim kutusu kullanılarak yönetilen bir derleme olarak Cω'ye maruz kalabilir . Veritabanı nesneleri, sunucu tarafından barındırılan ilişkisel veritabanını temsil etmek için Cω tarafından kullanılır. Bir Veritabanı nesnesi, her tablo veya görünüm için ortak bir özelliğe ve veritabanında bulunan her tablo değerli işlev için bir yönteme sahiptir. İlişkisel bir veritabanını sorgulamak için SQL tabanlı işleçlerden birine veya daha fazlasına girdi olarak tablo, görünüm veya tablo değerli bir işlev belirtilmelidir.

Aşağıdaki örnek program ve çıktı, Cω'deki ilişkisel bir veritabanını sorgulamak için SQL tabanlı işleçleri kullanma yeteneklerini gösterir. Bu örnekte kullanılan veritabanı, Microsoft SQL Server ile birlikte gelen örnek Northwind veritabanıdır. Örnekte kullanılan DB adı, sql2comega.exe kullanılarak oluşturulan Northwind.dll derlemesinin Northwind ad alanındaki global bir Veritabanı nesnesine karşılık gelir .

Yani, evet, en başından beri (hatta bakış açınıza bağlı olarak, en başından önce) LINQ açıkça SQL tabanlıydı ve özellikle SQL veritabanlarındaki verilere erişime izin vermeyi amaçladı.

.Net'te LINQ yöntemleri

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

C # (ve VB.NET) içindeki LINQ sorgu sözdizimi ile tutarlı olacak şekilde adlandırıldı

from x in source
where condition
select projection

SQL bilen insanlara aşina olacak şekilde tasarlanmıştır.

SELECT projection
FROM source x
WHERE condition

Benim için Seç ve Topla daha anlamlı. Varlık .Net'teki verileri sorgulamak ve işlemek için baskın yöntem haline geldikçe, Linq muhtemelen SQL aracılığıyla verilerle çalışmaya alışkın olan geliştiriciler tarafından giderek daha fazla kullanılmaktadır. Dolayısıyla, "Seç" gibi kelimeleri kullanmak bu geliştiriciler için daha mantıklıdır, çünkü bunlar alıştıkları anahtar kelimelerdir.