2008-12-13 23 views
5

Tôi bắt đầu thiết kế một ứng dụng mới và những gì tôi tự hỏi là ý kiến ​​của mọi người về Linq2SQL hoặc Linq2Entities và những gì họ cảm thấy là công nghệ tốt hơn để phát triển nhanh chóng.LINQ 2 SQL hoặc LINQ Entities

Tôi cũng đang thực hiện một số nghiên cứu về dịch vụ dữ liệu ADO.net.

Trả lời

8

Tôi là một fan hâm mộ lớn của LINQ to SQL nếu bạn đáp ứng các yêu cầu thiết kế như sau:

  • MS SQL Server như động cơ DB
  • phát triển RAD
  • 1-1 lập bản đồ lớp là tất cả đó là yêu cầu

Tôi đã không làm nhiều việc với Khung thực thể nhưng từ những gì tôi biết và những gì tôi đã làm là nó không có hiệu suất tốt khi được tạo từ cùng cơ sở dữ liệu với LINQ để sử dụng SQL.

Hiệu suất thấp hơn là do tính chất của khung thực thể, nó sử dụng ADO thay vì nhà cung cấp cụ thể cho máy chủ cơ sở dữ liệu bạn đang sử dụng.

+0

Linq2SQL cho phép một số phân lớp nhưng không linh hoạt lắm. Bạn phải sử dụng một cột làm phân biệt đối xử kiểu. Tôi muốn làm điều này trong một bảng phân cấp (nơi sự hiện diện của một fk để cùng một bảng cho thấy một mối quan hệ với một phụ huynh trong cùng một bảng), nhưng không thể làm cho nó hoạt động. – tvanfosson

+0

Đó là sự thật, bởi vì LINQ to SQL không được thiết kế với phân lớp trong tâm trí, và EF là. Nhưng điều đó - cùng với các tính năng khác của EF - cho biết thêm sự phức tạp, do đó chi phí lớn hơn. – Boyan

+0

Bạn phải có thiết kế bảng khá đơn giản/nhàm chán/đơn giản để sử dụng bất kỳ tính năng MS nào dễ dàng (TableAdapters, Linq2Sql, v.v.) mạnh mẽ – user7116

3

Tôi sẽ nói rằng đối với giản đồ cơ sở dữ liệu đơn giản đến vừa phải, LINq2SQL hoạt động rất tốt và dễ thiết lập và sử dụng hơn. Đây là những gì tôi sử dụng cho ORM của tôi với một số điều chỉnh nhỏ thông qua các lớp học một phần để hỗ trợ xác nhận và ủy quyền/kiểm toán. Tôi sử dụng trình thiết kế DBML và thêm các bảng/quan hệ của tôi. Tôi thay đổi DataContext để làm cho nó trừu tượng và xây dựng một triển khai cụ thể cho phép tôi cung cấp các chức năng của bảng/các thủ tục lưu sẵn (ánh xạ vào ngữ cảnh dữ liệu như các phương thức) cung cấp các móc để kiểm tra và ủy quyền. Tôi thực hiện các phương thức từng phần trên các lớp thực thể cho OnValidate và OnLoad để thực hiện cả việc xác thực và ủy quyền ở cấp bảng. Tôi thấy rằng điều này là khá nhiều tất cả tôi cần. Gần đây, tôi đã định nghĩa một giao diện và trình bao bọc cho bối cảnh dữ liệu cụ thể cũng như cho phép tôi giả lập nó trong các bài kiểm tra đơn vị của mình.

+0

Bạn có muốn nghe thêm về các cách bạn mở rộng L2S ​​ – RobS

+0

Có thể chia sẻ một số mã của bạn không, nó có giá trị đối với chúng tôi – Mostafa

+0

Số tiền hợp lý của những gì tôi đã thực hiện với LINQ2SQL có thể tìm thấy trên blog của tôi: http : //farm-fresh-code.blogspot.com – tvanfosson

1

Phiếu bầu của tôi được chuyển đến Linq-to-SQL. Nó phù hợp với kịch bản phát triển nhanh chóng của bạn; dễ dàng để bắt đầu, dễ sử dụng. Ngoài ra nó tạo ra các truy vấn SQL tốt/hiệu quả từ các biểu thức LINQ.

LINQ to-Entities rất khó, nếu bạn cố gắng sử dụng bất kỳ tính năng 'nâng cao' nào được cho là đặt nó sang L2S, bạn sẽ phải bắt đầu chỉnh sửa tệp mô hình EDMX bằng trình soạn thảo XML (bạn sẽ sớm chạy vào 'những hạn chế' trong nhà thiết kế, nơi giải pháp/giải pháp duy nhất được Microsoft khuyên dùng là sử dụng trình soạn thảo XML để xoay tay EDMX). Trên hết, nó có xu hướng tạo ra các truy vấn SQL thực sự kém/không hiệu quả.

Microsoft nói rằng phiên bản tiếp theo của Entity Framework sẽ tốt hơn rất nhiều và sẽ hỗ trợ tất cả các tính năng của L2S. Tuy nhiên phiên bản tiếp theo sẽ không được phát hành bất cứ lúc nào sớm nên cho đến lúc đó L2S là cược tốt nhất của bạn.

-1

LINQ to SQL là một kết thúc chết trong những ngày này bởi vì Microsoft sẽ không cập nhật nữa. Tôi đã sử dụng nó một lúc cho các dự án của riêng mình, nhưng tôi thấy nó không đủ mạnh so với SQL thực. Tất nhiên nó có vẻ dễ dàng hơn để chạy trong thời gian ngắn, nhưng trong quá trình phát triển chu kỳ ứng dụng của bạn, bạn sẽ thấy rằng bạn tận hưởng sức mạnh của SQL nhiều hơn.

Tôi nghĩ LINQ TO SQL chỉ nên được chấp nhận bởi những người phụ thuộc nhiều vào các lớp trừu tượng của khung và không có thời gian/năng lượng/mong muốn theo đuổi SQL.

Một điều nữa bạn nên nhớ là lớp bổ sung giữa SQL và ứng dụng của bạn có chi phí riêng.Sự khác biệt về tốc độ không phải là thứ mà bạn dễ dàng nhận thấy, nhưng nó ở đó.

Cá nhân tôi khuyên một người nào đó nên bắt đầu tốt nghiệp thẳng thắn với SQL và cho LINQ to SQL bỏ lỡ.

+0

Kết thúc chết? Là nó? Tôi không chắc chắn ... http://reddevnews.com/blogs/weblog.aspx?blog=3016 – KristoferA

+2

-1 không phải là từ tôi, nhưng lại "SQL thực" của bạn - bạn có thể trỏ L2S tại SPROC và các phương thức UDF để sử dụng nó như là một DAL trên đỉnh của một lớp TSQL cứng nhắc. –

+0

Xin chào Marc, tôi không quan tâm đến '-' cho một cái nhìn bất đồng ý kiến. Đó là mong đợi:) ... Nhưng tại sao tôi muốn đưa L2S như là một DAL trên một SPROC? Tại sao tôi không sử dụng Proc trực tiếp trong mã của tôi? L2S là để nuôi con bằng ORM cho người mới bắt đầu. Tôi không thấy bất kỳ lý do thuyết phục nào để áp dụng nó. (Ở đây có nhiều hơn '-') –

0

Tôi khuyên bạn nên xem xét các giải pháp không phải của microsoft cho ORM. nHibernate là một giải pháp tuyệt vời có tất cả các tính năng của cả hai khung công tác đó cùng với nhiều tính năng khác. Có một đường cong học tập dốc hơn của nó nhưng thông thạo nHibernate giúp với điều đó. Nó cũng có giá trị nỗ lực.

0

Không ai có thể nói bạn defenitly những gì là tốt hơn.

Cả hai công nghệ đều gặp sự cố (NHibernate cũng gặp sự cố).

Tôi đang sử dụng LINQ to SQL và hài lòng với nó. Đối với các vấn đề về quan điểm của tôi trong Linq-to-SQL thì nhỏ hơn EF = _ ^.

3

Để sử dụng với ADO.NET Dịch vụ dữ liệu (bạn đề cập đến), Khuôn khổ thực thể là công cụ hoạt động bên ngoài hộp. Nếu bạn muốn cập nhật dữ liệu với LINQ-to-SQL (thông qua ADO.NET Data Services), bạn cần thực hiện một số công việc để thực hiện IUpdatable. May mắn là tôi đã viết blog về điều đó this week.

Suy nghĩ tổng thể của tôi giữa hai được bao phủ here, nhưng tôi đã làm mềm một chút kể từ đó, xem here.

Về cơ bản, tại thời điểm tôi thích LINQ-to-SQL, nhưng tôi mong đợi EF có thể sử dụng được nhiều hơn trong phiên bản tiếp theo. Do đó tại sao tôi làm việc để có được LINQ-to-SQL làm việc với ADO.NET Data Services.

2

Tôi nghĩ Linq 2 Sql là một lựa chọn tuyệt vời. Một vài điểm:

  • Nó thực sự là nhanh, tôi nhớ đọc một blog gửi qua tại Rico Mariani's Performance Tidbits trong L2S ​​beta, nơi ông đo nó được gần như nhanh như ADO.Net đồng bằng cũ, và đó là trong phiên bản beta của nó .
  • Bạn có thể làm cả hai truy vấn LINQ cũng như làm việc với các thủ tục được lưu trữ và sql cũ tốt nếu bạn thích điều đó, và vẫn nhận được dữ liệu để ánh xạ đối tượng được thực hiện cho bạn.
  • Thực tế là Stackoverflow sử dụng L2S ​​chứng minh rằng nó có thể hoạt động trên một trang web có quy mô lớn.
  • Nó nhẹ hơn nhiều so với Khung thực thể, điều này tốt và xấu tùy thuộc vào những gì bạn cần. Nói chung, nếu nhu cầu của bạn không phải là siêu cao cấp, bạn thường có thể làm việc xung quanh bất kỳ vấn đề nào khá nhanh chóng.
13

Có, đã đồng ý với Slace.

Chỉ cần cẩn thận trong khuôn khổ bạn chọn, để đảm bảo nó đáp ứng mọi nhu cầu của bạn.

Ví dụ, tôi vừa rút ruột ra Entity Framework từ một dự án làm việc sau khi làm việc với nó khá kiên cố trong vài tuần qua, vì nó đã không tạo điều kiện cho nhu cầu của tôi, chủ yếu là do: -

  1. Các things you can't do in Linq to Entities (chẳng hạn như ánh xạ tới .net enum types (grr) và tăng nặng khi nhận 'NotSupportedException' ở gần mọi ngã rẽ nếu bạn cố gắng tìm kiếm câu lệnh truy vấn linq bằng cách gọi hàm hoặc gọi phương thức (xem liên kết)).
  2. Thiếu tải Lazy gốc (Tôi hiểu có những công cụ như EF Lazy LoadGen để tạo điều kiện thuận lợi cho việc này, nhưng nó không phải là thứ tôi muốn tích hợp).

Ngoài ra, các lệnh và khuôn khổ dường như thẳng về phía trước và gọn gàng, và lý do tôi đã đi với EF là:

  1. tôi tin rằng EF được nhắm mục tiêu nhiều hơn cho phát triển doanh nghiệp và nghĩ L2S là nhiều hơn cho những người có sở thích và là một khung giới hạn. Tuy nhiên với sự hiểu biết và cá nhân hơn nữa, không cần bất cứ điều gì trong EF tôi không thể làm với L2S, tôi hài lòng với L2S. Đặc biệt là nếu nó phù hợp với stackoverflow, khả năng mở rộng và hiệu quả được bảo hiểm cho tôi.
  2. Tùy chọn cho nhiều DBMS '(Tuy nhiên tôi chưa thấy điều này đang hoạt động)
  3. Tin đồn Microsoft là dropping support and investment on Linq to SQL.
  4. Tôi thích thực tế bạn có thể cập nhật bảng và thay đổi DB trong EF .edmx mà không phải xóa mô hình lược đồ hiện có (mà bạn buộc phải làm trong LINQ to SQL). Mặc dù, không phải là siêu gây phiền nhiễu trừ khi bạn đã tùy chỉnh bất kỳ thuộc tính nào trong lược đồ L2S của bạn (.dbml).

Đọc thêm (khác SO bưu điện):
Is LINQ to SQL Dead or Alive?

tôi rất thích chọn EF, tôi thực sự không biết phải làm gì với các L2S vs EF debarcle, và nếu L2S thực sự là một con vịt chết, nhún vai. gripe chính của tôi thừa nhận với EF là NotSupportedException của - Tôi có thể nhận được xung quanh tải lười biếng nếu tôi có thể thực hiện các cuộc gọi phương pháp trong linq mà không cần ...

+0

Bạn đã thử NHibernate chưa? –

0

Chúng tôi nghĩ L2S là tuyệt vời cho đến khi chúng tôi cố gắng cập nhật. Sau đó, nó là thảm hại. Đồng nghiệp của tôi đã làm hầu hết công việc này trong khi tôi làm những việc khác. Anh ấy đã nói về EF và những cách mà cấu hình quá mức làm cho nó lộn xộn khi sử dụng.

Tôi đã đề xuất rằng vì chúng tôi nhắm mục tiêu MSSQL và điều đó sẽ không thay đổi, anh ấy có thể hack tất cả các công cụ trừu tượng của nhà cung cấp cơ sở dữ liệu. Một thời gian sau, anh ấy nói với tôi đó là một gợi ý tốt và mã của anh ấy đơn giản hơn nhiều và ít khó khăn hơn để duy trì.


tôi tò mò về cơ sở mà trên đó câu trả lời này đã được bình chọn xuống. Nó mô tả kinh nghiệm thực tế, và nó thảo luận về một chiến lược thay thế và thành công tương đối của phương pháp đó. Bỏ phiếu xuống là câu trả lời sai lệch, thực tế không chính xác hoặc chỉ đơn giản là trolling. Khi điều này xảy ra, tôi đã thay đổi vị trí của mình trên toàn bộ điều kiện của EF và L2S, nhưng điều đó không thay đổi thực tế là bỏ phiếu chỉ vì nó thể hiện quan điểm khác với trẻ con và hoàn toàn phản đối tinh thần của StackOverflow.

+0

+1 - kinh nghiệm thực tế> kinh nghiệm lý thuyết – mynameiscoffey

0

Đây là một câu hỏi khá cũ, nhưng LinqToSql cổ vũ của những câu trả lời bình chọn hàng đầu liên quan đến tôi. Có những hạn chế đáng kể đối với LinqToSql.

Do not use the Visual Studio 2008 LinqToSql O/R Designer

The drawbacks of adopting Linq To Sql

Điều đó nói rằng, có những mặt hạn chế đáng kể cho EntityFramework là tốt.

Có nhiều tùy chọn tốt hơn nhiều sẵn có (NHibernate là tùy chọn tốt nhất hiện nay).

+0

Tôi kính trọng không đồng ý. Cũng như (tôi giả định) các nhà phát triển của trang web bạn đã đăng trên, vì StackOverflow sử dụng L2S ​​cho cơ chế kiên trì của nó. Nó không dành cho tất cả mọi người, nhưng tôi đã thành công lớn với nó trong một môi trường doanh nghiệp truy cập nhiều cơ sở dữ liệu từ ASP.NET. Nếu bạn đã mua vào toàn bộ ngăn xếp MS và được chấp nhận với các đối tượng thiếu máu gắn liền với 1-to-1 với các bảng DB của bạn, L2S là một giải pháp tuyệt vời. – mattmc3

Các vấn đề liên quan