Entity Framework VS LINQ to SQL VS ADO.NET với các thủ tục được lưu trữ? [đóng cửa]

430

Làm thế nào bạn đánh giá từng người trong số họ về:

Hiệu suất
Tốc độ phát triển
Mã gọn gàng, trực quan, có thể duy trì
Uyển chuyển
Nhìn chung

Tôi thích SQL của mình và vì vậy luôn là một fan hâm mộ cuồng nhiệt của ADO.NET và các thủ tục được lưu trữ nhưng gần đây tôi đã chơi với Linq to SQL và bị thổi bay bởi cách tôi viết ra lớp DataAccess nhanh chóng và đã quyết định chi tiêu đôi khi thực sự hiểu Linq sang SQL hoặc EF ... hoặc không?

Tôi chỉ muốn kiểm tra, rằng không có lỗ hổng lớn trong bất kỳ công nghệ nào trong số những công nghệ này sẽ khiến thời gian nghiên cứu của tôi trở nên vô dụng. Ví dụ: hiệu suất rất tệ, nó tuyệt vời cho các ứng dụng đơn giản nhưng chỉ có thể đưa bạn đến nay.

Cập nhật: Bạn có thể tập trung vào các EF VS L2S VS SP thay vì ORM VS SP không. Tôi chủ yếu quan tâm đến EF VS L2S. Nhưng tôi cũng muốn có chúng so sánh với các procs được lưu trữ vì SQl đơn giản là điều tôi biết rất nhiều.

— Nhà phát triển người Anh
nguồn

94

không mang tính xây dựng và có quá nhiều sự ủng hộ? ...;)

— Anh

34

Tôi không thấy lý do tại sao một người nào đó đánh dấu điều này không mang tính xây dựng. Nó có vẻ thực sự tốt với tôi. +1 từ tôi.

— Thanushka

10

Đây là một câu hỏi xuất sắc trong quan điểm của tôi. Cá nhân, tôi đã nhận thấy Entity Framework và tất cả các ORM tương tự ngoài đó chậm hơn so với mã ADO.Net đơn giản / đơn giản. Tôi đã làm bài kiểm tra này 2 năm trước và sau đó một tuần nữa. Tôi không chắc chắn về cách so sánh LINQ với SQL với EF. Nhưng ADO.Net sẽ luôn là hiệu suất tốt nhất. Nếu bạn muốn tiết kiệm thời gian phát triển, thì Entity Framework là một công cụ tốt nhưng chắc chắn không phải khi hiệu suất là mối quan tâm chính của bạn.

— Sunil

2

@Timless: Có xu hướng không dựa vào cơ chế cơ sở dữ liệu. Mỗi công cụ cơ sở dữ liệu có ngôn ngữ thủ tục được lưu trữ riêng, do đó có thêm học tập. 99,9% các nhà phát triển có thể dựa vào ORM, tạo ra mã khá tốt và tự động tạo SQL. Hiệu suất khác biệt là cận biên trong trường hợp CRUD đơn giản. Thủ tục lưu trữ là khó khăn hơn để phát triển và duy trì. Vài năm trước, khi không có ORM và không có gì được tạo ra một cách kỳ diệu và tự động của cơ sở dữ liệu. Viết SP được coi là không tốn thời gian, vì nó thay thế cho việc viết các câu lệnh SQL trong ứng dụng.

— LukLed

4

@Sunil là chính xác, mặc dù không đủ dài dòng. Vấn đề là mọi người đều nghĩ rằng mối quan tâm chính của họ là hiệu suất ứng dụng. Khi tôi nói về các ứng dụng đòi hỏi hiệu năng cao nhất, tôi nghĩ đến các giao dịch cơ sở dữ liệu khách hàng có khối lượng lớn của C ++ MMO hoặc khối lượng lớn trong hàng triệu người. Bạn thực sự nên tập trung vào các nguyên tắc hướng đối tượng như khả năng duy trì , khả năng đọc , sự thiếu hiểu biết dai dẳng và phân tách logic miền . Đặc biệt là khi tăng hiệu suất là nhỏ nhất hoặc không tồn tại trong nhiều trường hợp.

— Suamere

430

Trước hết, nếu bạn đang bắt đầu một dự án mới, hãy đi với Entity Framework ("EF") - giờ đây nó tạo ra SQL tốt hơn nhiều (giống như Linq to SQL) và dễ duy trì và mạnh hơn Linq to SQL (" L2S "). Khi phát hành .NET 4.0, tôi coi Linq to SQL là một công nghệ lỗi thời. MS đã rất cởi mở về việc không tiếp tục phát triển L2S nữa.

1) Hiệu suất

Đây là khó khăn để trả lời. Đối với hầu hết các hoạt động đơn thực thể ( CRUD ), bạn sẽ tìm thấy hiệu suất tương đương với cả ba công nghệ. Bạn phải biết làm thế nào để EF và Linq to SQL hoạt động để sử dụng chúng hết mức. Đối với các hoạt động có khối lượng lớn như truy vấn bỏ phiếu, bạn có thể muốn EF / L2S "biên dịch" truy vấn thực thể của mình để khung không phải liên tục tạo lại SQL hoặc bạn có thể gặp phải các vấn đề về khả năng mở rộng. (xem các chỉnh sửa)

Đối với các cập nhật hàng loạt trong đó bạn đang cập nhật lượng dữ liệu khổng lồ, SQL thô hoặc thủ tục được lưu trữ sẽ luôn hoạt động tốt hơn giải pháp ORM vì bạn không phải sắp xếp dữ liệu qua dây với ORM để thực hiện cập nhật.

2) Tốc độ phát triển

Trong hầu hết các kịch bản, EF sẽ thổi bay SQL / procs được lưu trữ khi nói đến tốc độ phát triển. Nhà thiết kế EF có thể cập nhật mô hình của bạn từ cơ sở dữ liệu của bạn khi nó thay đổi (theo yêu cầu), do đó bạn không gặp phải vấn đề đồng bộ hóa giữa mã đối tượng và mã cơ sở dữ liệu của bạn. Lần duy nhất tôi không cân nhắc sử dụng ORM là khi bạn đang thực hiện một ứng dụng loại báo cáo / bảng điều khiển nơi bạn không thực hiện bất kỳ cập nhật nào hoặc khi bạn tạo một ứng dụng chỉ để thực hiện các hoạt động bảo trì dữ liệu thô trên cơ sở dữ liệu.

3) Mã gọn gàng / duy trì

Chống tay xuống, EF đánh bại SQL / sprocs. Bởi vì các mối quan hệ của bạn được mô hình hóa, các phép nối trong mã của bạn tương đối không thường xuyên. Các mối quan hệ của các thực thể gần như hiển nhiên đối với người đọc đối với hầu hết các truy vấn. Không có gì tệ hơn là phải đi từ gỡ lỗi tầng này sang tầng khác hoặc thông qua nhiều tầng SQL / tầng trung lưu để hiểu những gì thực sự xảy ra với dữ liệu của bạn. EF đưa mô hình dữ liệu của bạn vào mã của bạn một cách rất mạnh mẽ.

4) Linh hoạt

Các procs được lưu trữ và SQL thô "linh hoạt" hơn. Bạn có thể tận dụng sprocs và SQL để tạo các truy vấn nhanh hơn cho trường hợp cụ thể lẻ và bạn có thể tận dụng chức năng DB gốc dễ dàng hơn so với bạn có thể và ORM.

5) Nhìn chung

Đừng để bị cuốn vào sự phân đôi sai lầm khi chọn ORM so với sử dụng các thủ tục được lưu trữ. Bạn có thể sử dụng cả hai trong cùng một ứng dụng và có lẽ bạn nên làm vậy. Các hoạt động hàng loạt lớn phải được thực hiện trong các thủ tục được lưu trữ hoặc SQL (mà thực tế có thể được gọi bởi EF) và nên sử dụng EF cho các hoạt động CRUD của bạn và hầu hết các nhu cầu của tầng lớp trung lưu. Có lẽ bạn sẽ chọn sử dụng SQL để viết báo cáo của mình. Tôi đoán đạo đức của câu chuyện vẫn giống như mọi khi. Sử dụng các công cụ thích hợp cho công việc. Nhưng sự mỏng manh của nó là, ngày nay EF rất tốt (kể từ .NET 4.0). Dành thời gian thực để đọc và hiểu sâu về nó và bạn có thể tạo một số ứng dụng hiệu suất cao, tuyệt vời một cách dễ dàng.

EDIT : EF 5 đơn giản hóa phần này một chút với Truy vấn LINQ được biên dịch tự động , nhưng đối với nội dung có khối lượng lớn thực sự, bạn chắc chắn sẽ cần kiểm tra và phân tích những gì phù hợp nhất với bạn trong thế giới thực.

— Dave Markle
nguồn

35

Câu trả lời hoàn toàn xuất sắc. Bây giờ tôi thực sự đang sử dụng EF để phát triển nhanh chóng một ứng dụng. Nếu hiệu suất trở thành một vấn đề, các procs được lưu trữ sẽ được đưa vào để cấu trúc lại các truy vấn EF hoạt động kém. Cảm ơn!

— Anh

17

@BritishDeveloper: Ngoài ra, đừng quên sức mạnh của việc sử dụng lượt xem. Chúng tôi đã thành công lớn với việc xác định một vài khung nhìn trong các dự án L2S của chúng tôi và tận dụng chúng trong đó khung dường như viết các truy vấn kém. Bằng cách đó, chúng tôi nhận được tất cả các lợi ích của việc sử dụng khung với tất cả các lợi ích của việc viết SQL của riêng chúng tôi.

— Dave Markle

5

Tôi cũng đang sử dụng Chế độ xem;) Thêm như là một cách giải quyết cho giới hạn db không chéo của EF. Ý tưởng tốt để sử dụng để tối ưu hóa mặc dù. Cảm ơn

— Anh

5

Chắc chắn là một phản ứng tuyệt vời. Chỉ muốn thêm một quan sát mà tôi có theo kinh nghiệm của riêng tôi với L2S vs EF4. Hoán đổi từ L2S -> EF4 sau khi chúng tôi nhận ra rằng chúng tôi có thể đang sử dụng một số RDMBS khác nhau ... nhưng, trong khi vẫn chạy MSSQL, hiệu suất giảm chủ yếu thể hiện chủ yếu trong khu vực GUI của ứng dụng của tôi. Liên kết dữ liệu với tập kết quả trong L2S nhanh hơn nhiều so với EF4. Đó là cùng một truy vấn trên cùng một DB chính xác. Một điều cần lưu ý ở đây là tôi đang trả lại 90k + hồ sơ nên sự khác biệt là khá rõ ràng. Có lẽ trên các bộ nhỏ hơn nó không phải là một vấn đề? Không chắc nó sẽ mở rộng như thế nào với các trang web vol cao ...

— bbqchickenrobot

5

Đáp ứng tốt. Tôi mới dành 4 tuần để làm việc với LINQ-to-Entity, cố gắng thu thập mọi thứ vào đó, trước khi nhận ra rằng bạn cần SQL nguyên gốc cho những thứ như sao chép hàng loạt, xóa hàng loạt, loại bỏ trùng lặp cực nhanh khỏi cơ sở dữ liệu, v.v. đúng công cụ cho công việc, không có gì xấu hổ khi kết hợp SQL gốc với khung LINQ to Entities.

— Contango

93

Thủ tục lưu trữ:

(+)

Linh hoạt tuyệt vời
Toàn quyền kiểm soát SQL
Hiệu suất cao nhất hiện có

(-)

Yêu cầu kiến thức về SQL
Thủ tục lưu trữ nằm ngoài tầm kiểm soát
Số lượng đáng kể "lặp lại chính mình" trong khi chỉ định cùng tên bảng và trường. Khả năng cao phá vỡ ứng dụng sau khi đổi tên một thực thể DB và thiếu một số tham chiếu đến nó ở đâu đó.
Chậm phát triển

ORM:

(+)

Phát triển nhanh
Mã truy cập dữ liệu hiện thuộc quyền kiểm soát nguồn
Bạn bị cô lập với những thay đổi trong DB. Nếu điều đó xảy ra, bạn chỉ cần cập nhật mô hình / ánh xạ của bạn ở một nơi.

(-)

Hiệu suất có thể kém hơn
Không có hoặc có ít quyền kiểm soát đối với SQL mà ORM tạo ra (có thể là lỗi không hiệu quả hoặc tệ hơn). Có thể cần phải can thiệp và thay thế nó bằng các thủ tục lưu trữ tùy chỉnh. Điều đó sẽ khiến mã của bạn lộn xộn (một số LINQ trong mã, một số SQL trong mã và / hoặc trong DB ngoài tầm kiểm soát nguồn).
Vì bất kỳ sự trừu tượng hóa nào cũng có thể tạo ra các nhà phát triển "cấp cao" không biết nó hoạt động như thế nào dưới mui xe

Sự đánh đổi chung là giữa việc có một sự linh hoạt tuyệt vời và mất rất nhiều thời gian so với việc bị hạn chế trong những gì bạn có thể làm nhưng hoàn thành nó rất nhanh.

Không có câu trả lời chung cho câu hỏi này. Đó là vấn đề của các cuộc chiến thánh. Cũng phụ thuộc vào một dự án trong tầm tay và nhu cầu của bạn. Chọn những gì làm việc tốt nhất cho bạn.

— AGuyCalledGerald
nguồn

47

Tôi không nghĩ rằng các điểm liên quan đến kiểm soát nguồn có liên quan. Lược đồ cơ sở dữ liệu, các thủ tục được lưu trữ, UDF, v.v ... đều có thể, và phải được kiểm soát nguồn.

— Lee Gunn

15

+1 choAs any abstraction can produce "high-level" developers having no idea how it works under the hood

— nawfal

3

Đồng ý, đối số kiểm soát nguồn là không chính xác. Chúng tôi luôn lưu trữ các kịch bản tạo cơ sở dữ liệu của chúng tôi trong svn. Làm thế nào bạn thậm chí có thể giữ cơ sở dữ liệu bên ngoài kiểm soát nguồn khi phát triển một ứng dụng cơ sở dữ liệu?

— Wout

3

EF không thực sự phù hợp với tính sẵn sàng cao và hiệu suất cao, tôi không phải là người của DBA nhưng tôi không thấy những gì EF cung cấp giúp việc viết mã dễ dàng hơn.

— Jamie

4

Vì vậy, chúng tôi đang từ bỏ tính linh hoạt, toàn quyền kiểm soát và hiệu suất để "phát triển nhanh" và tránh thay đổi mã nếu DB thay đổi. Âm thanh như sự lười biếng thuần túy đối với tôi.

— dùng2966445

18

câu hỏi của bạn về cơ bản là O / RM và viết tay SQL

Sử dụng ORM hoặc SQL đơn giản?

Hãy xem một số giải pháp O / RM khác ngoài kia, L2S không phải là giải pháp duy nhất (NHibernate, ActiveRecord)

http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software

để giải quyết các câu hỏi cụ thể:

Phụ thuộc vào chất lượng của giải pháp O / RM, L2S khá giỏi trong việc tạo SQL
Điều này thường nhanh hơn nhiều khi sử dụng O / RM một khi bạn tìm hiểu quy trình
Mã cũng thường gọn gàng hơn và dễ bảo trì hơn
SQL thẳng dĩ nhiên sẽ giúp bạn linh hoạt hơn, nhưng hầu hết các O / RM có thể thực hiện tất cả trừ các truy vấn phức tạp nhất
Nhìn chung, tôi khuyên bạn nên sử dụng O / RM, sự mất linh hoạt là không đáng kể

— Băng đen
nguồn

@David Cảm ơn, nhưng nó không phải là ORM vs SQL. Tôi đang tìm cách chuyển sang ORM và đang tự hỏi nên đầu tư thời gian vào việc học: EF hay L2S (trừ khi chúng là rác so với Procs được lưu trữ)

— BritishDeveloper

1

Tôi chắc chắn nói rằng chúng không phải là rác so với các procs được lưu trữ và một lợi ích phụ là bạn không có mã lây lan vào cơ sở dữ liệu. Cá nhân tôi thích L2S, nhưng tôi chưa làm được gì nhiều với EF vào thời điểm này và có vẻ như L2EF sẽ thay thế nó, vì vậy tôi sẽ đi EF. Ngoài ra, một khi bạn đi Linq, bạn không quay lại.

— BlackICE

13

LINQ-to-SQL là một phần công nghệ đáng chú ý, rất đơn giản để sử dụng, và bằng cách lớn tạo ra các truy vấn rất tốt cho phần cuối. LINQ-to-EF được dự kiến thay thế nó, nhưng trong lịch sử đã cực kỳ khó sử dụng và tạo ra SQL kém hơn nhiều. Tôi không biết tình trạng hiện tại, nhưng Microsoft hứa sẽ chuyển tất cả sự tốt đẹp của L2S sang L2EF, vì vậy có lẽ mọi thứ đã tốt hơn bây giờ.

Cá nhân, tôi rất không thích các công cụ ORM (xem chi tiết của tôi ở đây để biết chi tiết), và vì vậy tôi thấy không có lý do gì để ủng hộ L2EF, vì L2S cung cấp cho tôi tất cả những gì tôi mong muốn từ lớp truy cập dữ liệu. Trên thực tế, tôi thậm chí nghĩ rằng các tính năng L2S như ánh xạ thủ công và mô hình kế thừa làm tăng thêm sự phức tạp không cần thiết. Nhưng đó chỉ là tôi. ;-)

— Marcelo Cantos
nguồn

1

L2S là khá tốt, nhưng có nhược điểm mà Microsoft đã tuyên bố rằng về cơ bản họ sẽ không đầu tư nhiều vào việc mở rộng nó. Bạn có thể thấy kết quả của điều này đã có trong phiên bản mới nhất chỉ có một vài sửa lỗi và một số hỗ trợ cho kiểu dữ liệu SQL Server 2008 được thêm vào.

— FinnNk

Đồng ý, @FinnNk. Một thực tế đáng tiếc rằng việc sử dụng L2S có phần rủi ro do tình trạng ngang hàng của nó. Nhưng nếu họ thực sự đã loại bỏ hoàn toàn ủng hộ L2EF, tôi hoàn toàn nghi ngờ rằng sẽ có một con đường di chuyển, vì những điều sau đây vẫn được hưởng.

— Marcelo Cantos

3

Linq to EF đã trưởng thành và hiện sản xuất SQL tốt như L2S (kể từ .NET 4.0). L2EF ngày nay đẹp hơn L2S rất nhiều, vì ít nhất nó có thể cập nhật mô hình của bạn khi DB thay đổi, điều mà L2S không bao giờ có thể tự động làm được. Tôi cũng thích thực tế là bạn có thể ánh xạ các mối quan hệ M: M đơn giản với EF thành các mối quan hệ mà không cần phải có một thực thể trung gian. Nó làm cho mã sạch hơn nhiều.

— Dave Markle

2

Cảm ơn đã cập nhật @Dave. Tuy nhiên, tôi không đồng ý với nhận xét M: M. Các lược đồ tôi đã làm việc với hầu như luôn luôn phát triển các thuộc tính bổ sung trên các bảng tham gia. Điều này gây ra một sự thay đổi cấu trúc cho mô hình đối tượng, đòi hỏi rất nhiều mã làm lại. Tôi sẽ thay vì đối phó với các mối quan hệ trung gian rõ ràng ngay từ đầu.

— Marcelo Cantos

1

Có một cách tiếp cận hoàn toàn mới mà bạn có thể muốn xem xét nếu thứ bạn theo đuổi là sức mạnh và hiệu suất của các thủ tục được lưu trữ và sự phát triển nhanh chóng mà các công cụ như Entity Framework cung cấp.

Tôi đã dùng SQL + để lái thử trong một dự án nhỏ và nó thực sự là một điều đặc biệt. Về cơ bản, bạn thêm số lượng nhận xét vào các thói quen SQL của mình và những nhận xét đó cung cấp hướng dẫn cho trình tạo mã, sau đó xây dựng thư viện lớp hướng đối tượng thực sự tốt dựa trên thói quen SQL thực tế. Kiểu như khung thực thể ngược lại.

Các tham số đầu vào trở thành một phần của đối tượng đầu vào, tham số đầu ra và tập kết quả trở thành một phần của đối tượng đầu ra và thành phần dịch vụ cung cấp các lệnh gọi phương thức.

Nếu bạn muốn sử dụng các thủ tục được lưu trữ, nhưng vẫn muốn phát triển nhanh chóng, bạn có thể muốn xem qua công cụ này.

— Vincent
nguồn