Lý do đằng sau việc đặt tên của .NET Chọn (Bản đồ) và Tổng hợp (Giảm) là gì?


17

Trong các ngôn ngữ lập trình khác, tôi đã thấy Map và Giảm, và đó là những nền tảng của lập trình chức năng. Tôi không thể tìm thấy bất kỳ lý do hoặc lịch sử tại sao LINQ có Aggregate(giống như Reduce) và Select(giống như Map)?

Tại sao tôi hỏi là tôi phải mất một thời gian để hiểu nó là điều tương tự và tôi tò mò lý do cho việc này là gì.




Mặt khác, tôi rất muốn biết lý do đằng sau việc chọn tên "Bản đồ" và tổng hợp "Giảm" để bắt đầu.
Den

Câu trả lời:


32

Điều này chủ yếu đi vào lịch sử của LINQ.

LINQ ban đầu dự định giống như SQL và được sử dụng (phần lớn, mặc dù không độc quyền) để kết nối với cơ sở dữ liệu SQL. Điều này dẫn đến phần lớn thuật ngữ của nó dựa trên SQL.

Vì vậy, "chọn" đến từ SQL selecttuyên bố, và "tổng hợp" đến từ SQL chức năng tổng hợp (ví dụ, count, sum, avg, min,max ).

Đối với những người đặt câu hỏi về mức độ mà LINQ ban đầu liên quan đến SQL, tôi muốn tham khảo (ví dụ) các bài viết của Microsoft về Cω, một ngôn ngữ được Microsoft Research nghĩ ra và dường như là nơi mà hầu hết các kiến ​​thức cơ bản về LINQ đã hoạt động ra trước khi chúng được thêm vào C # và .NET.

Ví dụ, hãy xem xét một bài viết MSDN trên Cω , trong đó nói:

Toán tử truy vấn trong Cω

Cω thêm hai lớp toán tử truy vấn rộng vào ngôn ngữ C #:
- Toán tử dựa trên XPath để truy vấn các biến thành viên của đối tượng theo tên hoặc theo loại.
- Các toán tử dựa trên SQL để thực hiện các truy vấn tinh vi liên quan đến phép chiếu, nhóm và nối dữ liệu từ một hoặc nhiều đối tượng.

Ít nhất theo như tôi biết, các toán tử dựa trên XPath không bao giờ được thêm vào C #, chỉ để lại các toán tử được ghi lại (trước khi LINQ tồn tại) là dựa trên SQL.

Bây giờ, chắc chắn đúng là LINQ không giống với các toán tử truy vấn dựa trên SQL trong Cω. Cụ thể, LINQ tuân theo các đối tượng cơ bản của C # và gọi cú pháp chặt chẽ hơn nhiều so với C đã làm. Các truy vấn C followed theo cú pháp SQL thậm chí chặt chẽ hơn, do đó bạn có thể viết một cái gì đó như thế này (một lần nữa, được rút ra trực tiếp từ bài viết được liên kết ở trên):

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

Và vâng, cùng một bài viết nói về việc sử dụng các truy vấn dựa trên SQL để truy vấn dữ liệu đến từ cơ sở dữ liệu SQL thực tế:

Để kết nối với cơ sở dữ liệu SQL trong Cω, nó phải được hiển thị dưới dạng một tập hợp được quản lý (nghĩa là tệp thư viện .NET), sau đó được ứng dụng tham chiếu. Một cơ sở dữ liệu quan hệ có thể được hiển thị với Cω dưới dạng một tổ hợp được quản lý bằng cách sử dụng công cụ dòng lệnh sql2comega.exe hoặc hộp thoại Thêm cơ sở dữ liệu ... trong Visual Studio. Các đối tượng cơ sở dữ liệu được Cω sử dụng để thể hiện cơ sở dữ liệu quan hệ được lưu trữ bởi máy chủ. Một đối tượng cơ sở dữ liệu có một thuộc tính công khai cho mỗi bảng hoặc dạng xem và một phương thức cho mỗi hàm có giá trị bảng được tìm thấy trong cơ sở dữ liệu. Để truy vấn cơ sở dữ liệu quan hệ, một bảng, dạng xem hoặc hàm có giá trị bảng phải được chỉ định làm đầu vào cho một hoặc nhiều toán tử dựa trên SQL.

Chương trình và đầu ra mẫu sau đây cho thấy một số khả năng sử dụng các toán tử dựa trên SQL để truy vấn cơ sở dữ liệu quan hệ trong Cω. Cơ sở dữ liệu được sử dụng trong ví dụ này là cơ sở dữ liệu Northwind mẫu đi kèm với Microsoft SQL Server. Tên DB được sử dụng trong ví dụ này đề cập đến một thể hiện toàn cầu của một đối tượng Cơ sở dữ liệu trong không gian tên Northwind của cụm Northwind.dll được tạo bằng sql2comega.exe .

Vì vậy, có, ngay từ đầu (hoặc thậm chí trước khi bắt đầu, tùy thuộc vào quan điểm của bạn) LINQ rõ ràng dựa trên SQL và dự định cụ thể để cho phép truy cập dữ liệu trong cơ sở dữ liệu SQL.


5
Tôi không đồng ý rằng LINQ đã được phát minh cho các truy vấn SQL. LINQ dựa trên các hoạt động truy vấn trong , lần lượt kế thừa chúng từ X♯, dựa trên một bài báo Haskell cũ. Lưu ý rằng một trong những tác giả của các bài báo Haskell nói là Erik Meijer, người cũng tham gia thiết kế X và Cω sau đó, và tất nhiên là người thiết kế LINQ. Và rõ ràng ngay từ đầu, LINQ có thể được sử dụng để truy vấn tất cả mọi thứ, không chỉ SQL (nó được vận chuyển với LINQ-to-SQL, LINQ-to-XML và LINQ-to-Object từ ngày 1, ngay sau đó tiếp theo là
Lọ

4
LINQ-to-Entities), và trên thực tế, nhiều hơn so với truy vấn (về cơ bản là cú pháp Hiểu toàn bộ Monad ). Nó được thiết kế để làm quen với các lập trình viên SQL (và XQuery), nhưng chắc chắn không giới hạn ở điều đó. Theo một cách tương tự, Scala's Monad Comp Hiểu giống như forcác vòng lặp và Haskell trông giống như các khối mã mệnh lệnh kiểu C, và vì vậy Scala gọi hoạt động đơn điệu của nó flatMapvà Haskell gọi nó returnvì lý do tương tự: để phù hợp với "ảo ảnh" bị ngăn chặn (trước đây) lập trình viên mệnh lệnh.
Jörg W Mittag

2
@ JörgWMittag: Xem câu trả lời được chỉnh sửa. Tôi tin rằng tài liệu của Microsoft hỗ trợ các tuyên bố của tôi.
Jerry Coffin

3
+1 cho việc thực sự biện minh cho câu trả lời thay vì đoán mò. Bạn không thể có được nhiều nguồn có thẩm quyền hơn chính Microsoft.
milleniumorms

Cảm ơn, thưa ngài! Đây chính xác là loại câu trả lời tôi đã hy vọng nhận được.
Tx3

8

Các phương thức LINQ trong .Net

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

được đặt tên là phù hợp với cú pháp truy vấn LINQ trong C # (và VB.NET)

from x in source
where condition
select projection

được thiết kế để quen thuộc với những người biết SQL

SELECT projection
FROM source x
WHERE condition

2

Đối với tôi, Chọn và Tổng hợp có ý nghĩa hơn. Khi thực thể trở thành phương thức chi phối để truy vấn và thao tác dữ liệu trong .Net, Linq đang được sử dụng ngày càng nhiều bởi các nhà phát triển có lẽ đã quen làm việc với dữ liệu thông qua SQL. Vì vậy, sử dụng các từ như "Chọn" có ý nghĩa hơn đối với các nhà phát triển đó, vì đó là những từ khóa họ đã sử dụng.


4
"Ngày càng nhiều bởi các nhà phát triển, những người có lẽ đã quen làm việc với dữ liệu thông qua SQL" Tôi nghi ngờ điều này. Anh chàng mà tôi làm việc cùng với những người ca ngợi Entity Framework không thể hình dung anh ta cần phải làm một INNER JOINngày duy nhất khi Entity Framework không phải là một lựa chọn. Có lẽ hoàn toàn ngược lại. Ngày càng có nhiều người sử dụng LINQ hàng ngày, những người chủ động tránh viết SQL. Những người thoải mái trong SQL có lẽ chỉ cần làm nhiều hơn trong SQL.
jpmc26

1
Đó không phải là những gì tôi đã thấy. Chủ yếu những gì tôi tìm thấy (thông qua tìm kiếm công việc gần đây của tôi) là các nhà phát triển đã từng làm việc với dữ liệu bằng Thủ tục lưu trữ đang bắt đầu thực hiện tất cả các tập lệnh của họ trong bộ điều khiển. Đối với tôi, nó giúp Linq sử dụng các biểu thức quen thuộc. Tôi không nghi ngờ đó là trường hợp của "anh chàng bạn làm việc cùng", nhưng đó không phải là kinh nghiệm của tôi.
Christine
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.