Khung thực thể vs LINQ to SQL

Bây giờ .NET v3.5 SP1 đã được phát hành (cùng với VS2008 SP1), giờ đây chúng tôi có quyền truy cập vào khung thực thể .NET.

Câu hỏi của tôi là này. Khi cố gắng quyết định giữa việc sử dụng Entity Framework và LINQ to SQL làm ORM, sự khác biệt là gì?

Theo cách hiểu của tôi, Khung thực thể (khi được sử dụng với LINQ to Entity) có phải là 'người anh lớn' đối với LINQ to SQL không? Nếu đây là trường hợp - nó có lợi thế gì? Nó có thể làm gì mà LINQ to SQL không thể tự làm được?

LINQ to SQL chỉ hỗ trợ ánh xạ 1 đến 1 bảng cơ sở dữ liệu, khung nhìn, sprocs và các chức năng có sẵn trong Microsoft SQL Server. Đây là một API tuyệt vời để sử dụng để xây dựng truy cập dữ liệu nhanh đến cơ sở dữ liệu SQL Server được thiết kế tương đối tốt. LINQ2Query được phát hành lần đầu tiên với C # 3.0 và .Net Framework 3.5.

LINQ to Entities (ADO.Net Entity Framework) là API ORM (Object Relative Mapper) cho phép định nghĩa rộng các mô hình miền đối tượng và mối quan hệ của chúng với nhiều nhà cung cấp dữ liệu ADO.Net khác nhau. Như vậy, bạn có thể trộn và kết hợp một số nhà cung cấp cơ sở dữ liệu, máy chủ ứng dụng hoặc giao thức khác nhau để thiết kế kết hợp các đối tượng được xây dựng từ nhiều bảng, nguồn, dịch vụ, v.v. ADO.Net Framework được phát hành cùng với .Net Framework 3.5 SP1.

Đây là một bài viết giới thiệu hay về MSDN: Giới thiệu LINQ với dữ liệu quan hệ

Tôi nghĩ rằng câu trả lời nhanh và bẩn là

• LINQ to SQL là cách nhanh chóng và dễ dàng để làm điều đó. Điều này có nghĩa là bạn sẽ đi nhanh hơn và giao hàng nhanh hơn nếu bạn đang làm việc trên một cái gì đó nhỏ hơn.
• Entity Framework là cách hoàn toàn không có mục đích để thực hiện. Điều này có nghĩa là bạn sẽ mất nhiều thời gian hơn về phía trước, phát triển chậm hơn và linh hoạt hơn nếu bạn đang làm việc trên một cái gì đó lớn hơn.

LINQ to SQL có thật sự đã chết? của Jonathan Allen cho InfoQ.com

Matt Warren mô tả [LINQ to SQL] là một thứ "thậm chí không bao giờ tồn tại." Về cơ bản, nó chỉ được coi là độc lập để giúp họ phát triển LINQ cho đến khi ORM thực sự sẵn sàng.

...

Quy mô của Entity Framework khiến nó bỏ lỡ thời hạn .NET 3.5 / Visual Studio 2008. Nó đã được hoàn thành đúng lúc vì không may có tên ".NET 3.5 Service Pack 1", giống như một bản phát hành chính hơn là gói dịch vụ.

...

Các nhà phát triển không thích [Khung thực thể ADO.NET] vì tính phức tạp.

...

kể từ .NET 4.0, LINQ to Entities sẽ là giải pháp truy cập dữ liệu được đề xuất cho LINQ cho các tình huống quan hệ.

Có một số khác biệt rõ ràng được nêu trong bài viết mà @lars đã đăng, nhưng câu trả lời ngắn gọn là:

• L2S được liên kết chặt chẽ - thuộc tính đối tượng với trường cơ sở dữ liệu cụ thể hoặc ánh xạ đối tượng chính xác hơn vào một lược đồ cơ sở dữ liệu cụ thể
• L2S sẽ chỉ hoạt động với SQL Server (theo như tôi biết)
• EF cho phép ánh xạ một lớp đơn thành nhiều bảng
• EF sẽ xử lý các mối quan hệ MM
• EF sẽ có khả năng nhắm mục tiêu bất kỳ nhà cung cấp dữ liệu ADO.NET nào

Tiền đề ban đầu là L2S dành cho Phát triển nhanh và EF cho các ứng dụng cấp n "enterprisey" hơn, nhưng đó là bán L2S một chút.

LINQ to SQL

1. Nguồn dữ liệu đồng nhất: SQL Server
2. Đề xuất cho các dự án nhỏ chỉ khi cấu trúc dữ liệu được thiết kế tốt
3. Ánh xạ có thể được thay đổi mà không cần biên dịch lại với SqlMetal.exe
4. .dbml (Ngôn ngữ đánh dấu cơ sở dữ liệu)
5. Ánh xạ một-một giữa các bảng và các lớp
6. Hỗ trợ kế thừa TPH
7. Không hỗ trợ các loại phức tạp
8. Phương pháp lưu trữ đầu tiên
9. Cơ sở dữ liệu tập trung vào cơ sở dữ liệu
10. Được tạo bởi nhóm C #
11. Được hỗ trợ nhưng không cải thiện thêm dự định

Khuôn khổ thực

1. Nguồn dữ liệu không đồng nhất: Hỗ trợ nhiều nhà cung cấp dữ liệu
2. Đề xuất cho tất cả các dự án mới ngoại trừ:
   • những cái nhỏ (LINQ to SQL)
   • khi nguồn dữ liệu là một tệp phẳng (ADO.NET)
3. Ánh xạ có thể được thay đổi mà không cần biên dịch lại khi cài đặt mô hình và ánh xạ tệp Siêu dữ liệu Quy trình nhân tạo để sao chép vào thư mục đầu ra
4. .edmx (Mô hình dữ liệu thực thể) có chứa:
   • SSDL (Ngôn ngữ định nghĩa lược đồ lưu trữ)
   • Cơ sở dữ liệu (Ngôn ngữ định nghĩa lược đồ khái niệm)
   • MSL (Ngôn ngữ đặc tả bản đồ)
5. Ánh xạ một-một, một-nhiều, nhiều-một giữa các bảng và các lớp
6. Hỗ trợ kế thừa:
   • TPH (Bảng theo phân cấp)
   • TPT (Bảng mỗi loại)
   • TPC (Bảng trên mỗi lớp bê tông)
7. Hỗ trợ các loại phức tạp
8. Cách tiếp cận mã đầu tiên, mô hình đầu tiên, lưu trữ đầu tiên
9. Giao diện trung tâm ứng dụng của cơ sở dữ liệu
10. Được tạo bởi nhóm SQL Server
11. Tương lai của API dữ liệu Microsoft

Xem thêm:

• LINQ To SQL Vs Entity Framework
• Sự khác biệt giữa LINQ to SQL và Entity Framework
• Khung thực thể so với LINQ TO SQL

Trải nghiệm của tôi với Entity Framework ít hơn sao. Đầu tiên, bạn phải kế thừa từ các lớp cơ sở của EF, vì vậy hãy nói lời tạm biệt với POCOs. Thiết kế của bạn sẽ phải ở xung quanh EF. Với LinqtoQuery tôi có thể sử dụng các đối tượng kinh doanh hiện có của mình. Ngoài ra, không có tải lười biếng, bạn phải tự thực hiện điều đó. Có một số công việc xung quanh để sử dụng POCO và lười tải, nhưng chúng tồn tại IMHO vì EF chưa sẵn sàng. Tôi dự định sẽ quay lại với nó sau 4.0

Tôi tìm thấy một câu trả lời rất hay ở đây giải thích khi nào nên sử dụng những gì trong những từ đơn giản:

Nguyên tắc cơ bản cho việc sử dụng khung nào là cách lập kế hoạch chỉnh sửa dữ liệu của bạn trong lớp trình bày.

• Linq-To-Sql - sử dụng khung này nếu bạn có kế hoạch chỉnh sửa mối quan hệ một-một của dữ liệu trong lớp trình bày của bạn. Có nghĩa là bạn không có kế hoạch kết hợp dữ liệu từ nhiều hơn một bảng trong bất kỳ một chế độ xem hoặc trang nào.

• Entity Framework - sử dụng khung này nếu bạn có kế hoạch kết hợp dữ liệu từ nhiều hơn một bảng trong chế độ xem hoặc trang của bạn. Để làm cho điều này rõ ràng hơn, các điều khoản trên dành riêng cho dữ liệu sẽ được thao tác trong chế độ xem hoặc trang của bạn, không chỉ hiển thị. Điều này là quan trọng để hiểu.

Với Khung thực thể, bạn có thể "hợp nhất" dữ liệu được gắn thẻ với nhau để trình bày cho lớp trình bày ở dạng có thể chỉnh sửa và sau đó khi biểu mẫu đó được gửi, EF sẽ biết cách cập nhật TẤT CẢ dữ liệu từ các bảng khác nhau.

Có lẽ có nhiều lý do chính xác hơn để chọn EF trên L2S, nhưng đây có lẽ là lý do dễ hiểu nhất. L2S không có khả năng hợp nhất dữ liệu để xem bản trình bày.

Ấn tượng của tôi là cơ sở dữ liệu của bạn khá tuyệt vời hoặc được thiết kế rất tệ nếu Linq2Sql không phù hợp với nhu cầu của bạn. Tôi có khoảng 10 trang web cả lớn hơn và nhỏ hơn đều sử dụng Linq2Sql. Tôi đã xem xét và khung Entity nhiều lần nhưng tôi không thể tìm thấy lý do chính đáng để sử dụng nó trên Linq2Sql. Điều đó nói rằng tôi cố gắng sử dụng cơ sở dữ liệu của mình làm mô hình để tôi đã có ánh xạ 1 đến 1 giữa mô hình và cơ sở dữ liệu.

Ở công việc hiện tại của tôi, chúng tôi có một cơ sở dữ liệu với hơn 200 bảng. Một cơ sở dữ liệu cũ với nhiều giải pháp tồi nên tôi có thể thấy lợi ích của Entity Framework so với Linq2Sql nhưng tôi vẫn thích thiết kế lại cơ sở dữ liệu vì cơ sở dữ liệu là công cụ của ứng dụng và nếu cơ sở dữ liệu được thiết kế kém và chậm thì ứng dụng của tôi cũng sẽ chậm Sử dụng khung Entity trên cơ sở dữ liệu như vậy có vẻ như là một quickfix để ngụy trang mô hình xấu nhưng nó không bao giờ có thể ngụy trang hiệu năng xấu mà bạn có được từ cơ sở dữ liệu đó.

Bạn có thể tìm thấy một so sánh tốt ở đây:

http://www.dotnet-tricks.com/Tutorial/entityframework/1M5W300314-Difference-b between-LINEQ-to-MySQL-and-Entity-Framework.html

http://www.c-sharpcorner.com/bloss/entity-framework-vs-linq-to-sql1

Các câu trả lời ở đây đã đề cập đến nhiều điểm khác biệt giữa Linq2Sql và EF, nhưng có một điểm quan trọng chưa được chú ý nhiều: Linq2Sql chỉ hỗ trợ SQL Server trong khi EF có nhà cung cấp cho RDBMS sau:

Được cung cấp bởi Microsoft:

• Trình điều khiển ADO.NET cho SQL Server, OBDC và OLE DB

Thông qua các nhà cung cấp bên thứ ba:

• MySQL
• Oracle
• DB2
• VistaDB
• SQLite
• PostgreSQL
• Thông tin
• U2
• Sybase
• Synergex
• Chim lửa
• Npgs

đến tên một vài.

Điều này làm cho EF trở thành một sự trừu tượng hóa lập trình mạnh mẽ đối với kho dữ liệu quan hệ của bạn, có nghĩa là các nhà phát triển có một mô hình lập trình nhất quán để làm việc với bất kể kho lưu trữ dữ liệu cơ bản. Điều này có thể rất hữu ích trong các tình huống bạn đang phát triển một sản phẩm mà bạn muốn đảm bảo sẽ tương tác với một loạt các RDBMS phổ biến.

Một tình huống khác mà sự trừu tượng đó hữu ích là bạn là thành viên của nhóm phát triển làm việc với một số khách hàng khác nhau hoặc các đơn vị kinh doanh khác nhau trong một tổ chức và bạn muốn cải thiện năng suất của nhà phát triển bằng cách giảm số lượng RDBMS mà họ phải trở thành quen thuộc để hỗ trợ một loạt các ứng dụng khác nhau trên các RDBMS khác nhau.

Tôi thấy rằng tôi không thể sử dụng nhiều cơ sở dữ liệu trong cùng một mô hình cơ sở dữ liệu khi sử dụng EF. Nhưng trong linq2sql tôi chỉ có thể bằng tiền tố tên lược đồ với tên cơ sở dữ liệu.

Đây là một trong những lý do ban đầu tôi bắt đầu làm việc với linq2sql. Tôi không biết nếu EF đã cho phép chức năng này, nhưng tôi nhớ đọc rằng nó được dành cho nó không cho phép điều này.

Nếu cơ sở dữ liệu của bạn đơn giản và đơn giản, LINQ to SQL sẽ làm. Nếu bạn cần các thực thể logic / trừu tượng trên đầu các bảng của mình, thì hãy truy cập Entity Framework.

Chưa hỗ trợ các kiểu dữ liệu SQL 2008 duy nhất. Sự khác biệt từ quan điểm của tôi là Entity vẫn có cơ hội xây dựng một mô hình xung quanh kiểu dữ liệu địa lý của tôi trong một số bản phát hành trong tương lai và Linq to SQL, bị bỏ rơi, sẽ không bao giờ.

Tự hỏi có chuyện gì với nHibernate hay OpenAccess ...

Tôi nghĩ rằng nếu bạn cần phát triển một thứ gì đó nhanh chóng mà không có thứ lạ ở giữa và bạn cần cơ sở để có các thực thể đại diện cho các bảng của bạn:

Linq2Sql có thể là một đồng minh tốt, sử dụng nó với LinQ giải phóng thời gian phát triển tuyệt vời.

Tôi đang làm việc cho khách hàng có một dự án lớn đang sử dụng Linq-to-SQL. Khi dự án bắt đầu, đó là sự lựa chọn rõ ràng, bởi vì Entity Framework đang thiếu một số tính năng chính tại thời điểm đó và hiệu suất của Linq-to-SQL tốt hơn nhiều.

Bây giờ EF đã phát triển và Linq-to-SQL đang thiếu hỗ trợ async, điều này rất tốt cho các dịch vụ có khả năng mở rộng cao. Đôi khi chúng tôi có hơn 100 yêu cầu và mặc dù chúng tôi đã tối ưu hóa cơ sở dữ liệu của mình, hầu hết các truy vấn vẫn mất vài mili giây để hoàn thành. Do các cuộc gọi cơ sở dữ liệu đồng bộ, luồng bị chặn và không có sẵn cho các yêu cầu khác.

Chúng tôi đang suy nghĩ để chuyển sang Entity Framework, chỉ dành cho tính năng này. Thật đáng tiếc khi Microsoft đã không triển khai hỗ trợ không đồng bộ vào Linq-to-SQL (hoặc nguồn mở nó để cộng đồng có thể làm điều đó).

Phụ lục tháng 12 năm 2018: Microsoft đang chuyển sang .NET Core và Linq-2-SQL không hỗ trợ trên .NET Core, vì vậy bạn cần chuyển sang EF để đảm bảo bạn có thể di chuyển sang EF.Core trong tương lai.

Ngoài ra còn có một số tùy chọn khác để xem xét, chẳng hạn như LLBLGen . Đó là một giải pháp ORM trưởng thành đã tồn tại từ lâu và đã được chứng minh nhiều bằng chứng trong tương lai sau đó là các giải pháp dữ liệu MS (ODBC, ADO, ADO.NET, Linq-2-SQL, EF, EF.core).

Linq-to-SQL

Nó là nhà cung cấp, nó chỉ hỗ trợ SQL Server. Đây là một công nghệ ánh xạ để ánh xạ các bảng cơ sở dữ liệu SQL Server sang các đối tượng .NET. Đây là nỗ lực đầu tiên của Microsoft tại ORM - Mapper Relative Relper.

Linq-to-Thực thể

Cũng giống như vậy, nhưng sử dụng Entity Framework trong nền, như ORM - một lần nữa từ Microsoft, Nó hỗ trợ nhiều cơ sở dữ liệu của khung thực thể là nhà phát triển có thể làm việc trên bất kỳ cơ sở dữ liệu nào, không cần phải học cú pháp để thực hiện bất kỳ hoạt động nào trên các cơ sở dữ liệu khác nhau

Theo kinh nghiệm cá nhân của tôi, Ef tốt hơn (nếu bạn không biết gì về SQL) hiệu suất trong LINQ nhanh hơn một chút so với lý do ngôn ngữ LINQ được viết bằng lambda.