他のプログラミング言語では、MapとReduceを見てきましたが、それらは関数型プログラミングの基礎です。LINQがAggregate
(と同じReduce
)およびSelect
(と同じ)を持つ理由や歴史を見つけることができませんでしたMap
か?
私が尋ねているのは、それが同じことだと理解するのに時間がかかったからです。そして、私はこの理由を知りたいのです。
他のプログラミング言語では、MapとReduceを見てきましたが、それらは関数型プログラミングの基礎です。LINQがAggregate
(と同じReduce
)およびSelect
(と同じ)を持つ理由や歴史を見つけることができませんでしたMap
か?
私が尋ねているのは、それが同じことだと理解するのに時間がかかったからです。そして、私はこの理由を知りたいのです。
回答:
これは主にLINQの歴史に由来します。
LINQはもともと SQLに似たものであり、SQLデータベースに接続するために(主に、排他的ではありませんが)使用されていました。これにより、その用語の多くはSQLに基づいています。
だから、「選択」のSQLから来たselect
声明、および「集約」は、SQL集約関数から来た(例えば、count
、sum
、avg
、min
、max
)。
LINQが元々SQLに関連していた程度に疑問を抱く人のために、MicrosoftのCωに関する記事を参照します。 C#および.NETに追加される前に出力されます。
たとえば、次のようなCωに関するMSDNの記事を考えてみましょう。
Cωのクエリ演算子
Cωは、C#言語に2つの広範なクラスのクエリ演算子を追加します。-
オブジェクトのメンバー変数を名前またはタイプでクエリするためのXPathベースの演算子。
-1つ以上のオブジェクトからのデータの投影、グループ化、結合を含む高度なクエリを実行するためのSQLベースの演算子。
少なくとも私の知る限り、XPathベースの演算子はC#に追加されることはなく、文書化された(LINQが存在する前の)演算子のみがSQLに直接基づくものとして残されました。
さて、LINQがCωのSQLベースのクエリ演算子と同一ではないことは確かです。特に、LINQはC#の基本オブジェクトと関数呼び出しの構文に従い、Cωよりもはるかに厳密です。CωクエリはSQL構文にさらに厳密に従っていたため、次のようなものを書くことができます(再び、上記のリンク先の記事から直接引用)。
rows = select c.ContactName, o.ShippedDate
from c in DB.Customers
inner join o in DB.Orders
on c.CustomerID == o.CustomerID;
そして、はい、同じ記事では、SQLベースのクエリを使用して実際のSQLデータベースからのデータをクエリすることについて具体的に説明しています。
CωでSQLデータベースに接続するには、マネージアセンブリ(つまり、.NETライブラリファイル)として公開する必要があります。このアセンブリは、アプリケーションによって参照されます。リレーショナルデータベースは、sql2comega.exeコマンドラインツールまたはVisual Studio内から[ データベーススキーマの追加... ]ダイアログを使用して、マネージアセンブリとしてCωに公開できます。データベースオブジェクトは、サーバーによってホストされるリレーショナルデータベースを表すためにCωによって使用されます。データベースオブジェクトは、各表またはビューのパブリックプロパティ、およびデータベースで見つかった各テーブル値関数のための方法を有しています。リレーショナルデータベースをクエリするには、1つ以上のSQLベースの演算子への入力として、テーブル、ビュー、またはテーブル値関数を指定する必要があります。
次のサンプルプログラムと出力は、SQLベースの演算子を使用してCωのリレーショナルデータベースを照会する機能の一部を示しています。この例で使用するデータベースは、Microsoft SQL Serverに付属のサンプルNorthwindデータベースです。この例で使用されている名前DBは、sql2comega.exeを使用して生成されたNorthwind.dllアセンブリのNorthwind名前空間にあるデータベースオブジェクトのグローバルインスタンスを指します。
そのため、はい、最初から(またはあなたの視点によっては開始前でも)LINQは明示的にSQLに基づいており、特にSQLデータベースのデータへのアクセスを許可することを目的としていました。
for
ループのように見え、HaskellのCスタイルの命令コードブロックのように見えるため、Scalaはモナド演算をflatMap
呼び出し、Haskellはreturn
同じ理由で呼び出します。(元)命令型プログラマ。
私にとって、Select and Aggregateの方が理にかなっています。エンティティが.Netでデータをクエリおよび操作する主要な方法になると、Linqは、SQLを介してデータを操作することに慣れている開発者によってますます使用されています。そのため、これらの開発者にとっては「選択」などの単語を使用する方が理にかなっています。これは、それらが慣れ親しんでいるキーワードだからです。
INNER JOIN
Entity Frameworkがオプションではなかったときに1日だけをやる必要があるとは考えられませんでした。おそらくまったく逆です。SQLの作成を積極的に避けているLINQを毎日使用する人が増えています。SQLに慣れている人は、おそらくSQLでもっと多くのことをするでしょう。