Entity Framework 4 so với NHibernate [đã đóng]

Rất nhiều người đã nói về Entity Framework phiên bản đầu tiên trên web (cũng trên stackoverflow) và rõ ràng đó không phải là một lựa chọn tốt khi chúng ta đã có giải pháp thay thế tốt hơn như NHibernate. Nhưng tôi không thể tìm thấy so sánh tốt giữa Entity Framework 4 và NHibernate. Có thể nói ngày nay NHibernate là công ty dẫn đầu trong số tất cả các ORM .NET, nhưng liệu chúng ta có thể mong đợi Entity Framework 4 sẽ thay thế NHibernate khỏi vị trí này. Tôi nghĩ nếu Microsoft thực sự đưa các tính năng rất tốt vào EF4 thì nó có thể tạo ra sự cạnh tranh tốt với NHibernate vì nó có tích hợp Visual Studio, dễ làm việc hơn và ưu tiên luôn dành cho các sản phẩm MS ở hầu hết các cửa hàng.

EF4 có một câu trả lời rõ ràng về phát triển n-tier, trong "các thực thể tự theo dõi". Không ai đã phát hành mã có thể so sánh cho NHib.

NHib có nhiều tính năng chưa được đề cập đến như là một phần của EF4. Chúng bao gồm tích hợp bộ nhớ cache cấp hai. Nó cũng có tính linh hoạt cao hơn trong việc lập bản đồ kế thừa, tích hợp tốt hơn với các hàm procs / cơ sở dữ liệu được lưu trữ / SQL tùy chỉnh / trình kích hoạt, hỗ trợ các thuộc tính công thức, v.v. IMO về cơ bản nó chỉ trưởng thành hơn với tư cách là một ORM.

Cập nhật: Tôi đã không sử dụng Entity Framework kể từ phiên bản 4.0, vì vậy câu trả lời của tôi có thể đã lỗi thời. Tôi vẫn đang sử dụng NH hoặc ADO .NET thuần túy trong các dự án của mình. Và tôi thậm chí không muốn xem có gì mới trong EF kể từ 4.0, bởi vì NH hoạt động hoàn hảo.

Trên thực tế, khá dễ dàng để so sánh chúng khi bạn đã sử dụng cả hai. Có một số hạn chế nghiêm trọng với EF4, tôi có thể kể tên một số hạn chế mà tôi gặp phải:

Các vấn đề về EF4:

• Háo hức Đang tải và định hình kết quả : Hệ thống tải háo hức EF4 (Bao gồm ("Đường dẫn")) tạo ra SQL không đúng, với phép lặp của JOIN, sẽ thực thi chậm hơn hàng nghìn (không phải theo nghĩa đen) thời gian đối với các mối quan hệ nhiều-nhiều sau đó viết tay SQL (đó là hiệu quả không sử dụng được).
• Materializer không thể hiện thực hóa các thực thể được liên kết : Nếu bạn có thể nghĩ rằng mình có thể khắc phục sự cố trước đó bằng cách cung cấp truy vấn SQL của riêng bạn, thì bạn đã nhầm. EF4 không thể hiện thực hóa (ánh xạ) các thực thể được liên kết từ truy vấn JOIN SQL, nó chỉ có thể tải dữ liệu từ một bảng (Vì vậy, nếu bạn có Order.Product, SELECT * FROM order LEFT JOIN Product sẽ chỉ khởi tạo đối tượng Order, Product sẽ vẫn trống, nghĩ rằng tất cả dữ liệu cần thiết được tìm nạp trong truy vấn để bắt nó). Điều này có thể được khắc phục bằng cách sử dụng tiện ích bổ sung cộng đồng EFExtensions, nhưng mã bạn sẽ phải viết cho điều này thực sự xấu (tôi đã thử).

• Các thực thể tự theo dõi: Nhiều người nói rằng các thực thể Tự theo dõi rất thú vị để phát triển N-tier, bao gồm cả câu trả lời hàng đầu trong chủ đề này. Tôi nghĩ rằng tôi thậm chí chưa thử họ, tôi có thể nói rằng họ không. truy cập cơ sở sau đó? Bất kỳ cách nào bạn sẽ phải tải dữ liệu mà người dùng sắp thay đổi từ DB, hãy kiểm tra xem dữ liệu đó có tồn tại | không tồn tại hay không, kiểm tra quyền, v.v. Bạn không thể tin tưởng người dùng về trạng thái thực thể mà anh ta đang gửi đến máy chủ, bạn vẫn sẽ phải tải thực thể này từ DB và xác định trạng thái của nó và những thứ khác, vì vậy thông tin này là vô ích, cũng như các thực thể Tự theo dõi trừ khi bạn tạo một hệ thống n-tier riêng đáng tin cậy để sử dụng nội bộ, trong trường hợp đó, bạn có thể cung cấp đơn giản Quyền truy cập DB.

• Ghi nhật ký, Sự kiện, tích hợp logic nghiệp vụ: EF4 giống như hộp đen, nó làm một việc gì đó và bạn không biết nó làm gì. Chỉ có một sự kiện OnSavingChanges nơi bạn có thể đặt một số logic nghiệp vụ mà bạn cần chạy trước khi điều gì đó xảy ra với DB và nếu bạn cần áp dụng một số thay đổi cho các đối tượng nghiệp vụ trước khi điều gì đó xảy ra, bạn sẽ phải tìm hiểu trong ObjectStateManager, và điều này thực sự xấu xí , mã có thể trở nên rất lớn. Ví dụ: nếu bạn sử dụng mẫu Kho lưu trữ và những gì sẽ được thông báo về các thay đổi được thực hiện đối với DB theo cách đối tượng sạch, bạn sẽ gặp khó khăn khi thực hiện điều này với EF.

• Khả năng mở rộng: Tất cả mã EF là riêng tư và nội bộ, nếu bạn không thích điều gì đó (và bạn sẽ không thích RẤT NHIỀU nếu bạn nghiêm túc về việc sử dụng EF), không có cách nào bạn sẽ thay đổi điều này một cách dễ dàng, trên thực tế, tôi chắc chắn việc viết ORM của riêng bạn từ đầu sẽ dễ dàng hơn (tôi đã làm) sau đó làm cho EF hoạt động như bạn cần. Ví dụ, hãy xem nguồn EFExtensions, nó dựa trên các phương thức mở rộng và các "hack" khác nhau để làm cho EF dễ sử dụng hơn một chút và mã này khá xấu (và đó không phải là lỗi của tác giả, khi mọi thứ trong EF là riêng tư thì đây là điều duy nhất cách để mở rộng nó).

Tôi có thể tiếp tục viết những điều tồi tệ về EF và tôi đã cảm thấy đau đớn như thế nào khi làm việc với nó trong 20 trang, và có lẽ tôi sẽ làm vậy.

Còn NHibernate thì sao? Đó là một cấp độ hoàn toàn khác, nó giống như so sánh PHP với C #, EF4 giống như trong thời kỳ đồ đá, nó giống như EF chậm hơn 10 năm so với NHibernate trong quá trình phát triển, và thực tế là như vậy, Hibernate được bắt đầu vào năm 2001. Nếu bạn có thời gian rảnh để tìm hiểu và bật Nhibernate, hãy thực hiện.

Vấn đề là như thế này. Theo tôi, NHibernate và Entity Framework thực sự dành cho hai đối tượng khác nhau. NHibernate sẽ là lựa chọn của tôi trong việc xây dựng một hệ thống với các ánh xạ, công thức và ràng buộc phức tạp (về cơ bản là bất cứ thứ gì dành cho doanh nghiệp). Nếu tôi muốn chạy thành công với quyền truy cập dữ liệu đơn giản, tôi sẽ sử dụng Entity Framework hoặc LINQ-to-SQL. NHibernate không có trải nghiệm "kéo và thả" rõ ràng như EF. Cả hai đều có điểm mạnh và điểm hạn chế. Nói thẳng ra, so sánh chúng với táo với táo, bạn chẳng đi đến đâu.

Nếu bạn nghĩ rằng bạn có thể muốn chạy mã của mình trên Mono, NHibernate có lẽ là lựa chọn tốt hơn bất kể danh sách kiểm tra tính năng nói gì ...

Chỉnh sửa, 13/8/2012:

Entity Framework đã có nguồn mở và hiện được đưa vào Mono kể từ 2.11.3. Câu trả lời này hiện đã lỗi thời và không nên dựa vào.

http://weblogs.asp.net/scottgu/archive/2012/07/19/entity-framework-and-open-source.aspx

Tôi nghĩ về điều này là EF4.0 đã đi một chặng đường dài kể từ 1.0 và đang bắt kịp Nhibernate về chức năng, nhưng nó chưa phải là tất cả.

Tuy nhiên, đó là Microsoft, và thực hiện 100% những gì 95% ứng dụng cần nó làm. Tuy nhiên, NHibernate đã và đang làm điều tương tự trong nhiều năm. Đến phiên bản 5.0 hoặc 6.0 có thể bắt kịp, hoặc thậm chí vượt qua NHibernate.

Đây là lời khuyên của tôi - nếu bạn có thời gian để tìm hiểu cả hai, thì hãy làm điều đó. Có một số lý do để chọn cái này hơn cái kia. Nếu bạn đang viết mã cho một công ty, thật thực tế khi mong đợi có được những nhân viên quen thuộc với EF, vì nó có trong tất cả các cuốn sách và những gì trẻ em học ở trường đại học. Nếu EF đáp ứng được yêu cầu của bạn (hãy suy nghĩ về vấn đề này rất lâu và khó trước khi chỉ nói có), thì đó là một giải pháp hoàn toàn tốt cho hiện tại và trong một vài năm tới nó có thể (ok, rất có thể) sẽ vượt qua NHibernate.

NHibernate là một sản phẩm rất trưởng thành với EF một vài năm và rất có thể sẽ làm được mọi thứ bạn muốn làm và sau đó là một số. Nó đã là ORM tốt nhất trong một thời gian và rất nhiều người sử dụng nó.

Tôi nghĩ rằng thực tế là EF 4 sẽ có khả năng sử dụng POCO và tải chậm trễ sẽ rất lớn. Tôi chắc chắn có thể thấy nó đạt được sức hút với bản phát hành mới.

Có một xu hướng rõ ràng là EF ngày càng phổ biến hơn NHibernate, xem hình.

2 xu của tôi: chúng tôi sử dụng ef trên ứng dụng máy tính để bàn của chúng tôi cho một số bộ nhớ đệm, v.v. - không tải. Một NHib ở phía máy chủ - sử dụng phiên không trạng thái, tạo id hilo và hàng loạt. Là khá nhanh trong việc chèn 3k + tin nhắn trong db mỗi giây. Ngoài ra, nó rất linh hoạt và hỗ trợ nhiều dbs, điều này rất quan trọng đối với sản phẩm của chúng tôi.

Ánh xạ trực tiếp đến các thủ tục được lưu trữ với sự kết hợp của Linq cho một lớp logic có vẻ là cách tiếp cận dễ dàng nhất. Không có xml. Chỉ tạo sql cho các truy vấn thú vị ít được sử dụng hoặc không phù hợp với các thủ tục được lưu trữ.

Các đối tượng tải và lưu trữ thông qua các SP tiêu chuẩn. Cách tiếp cận này cho phép sử dụng hai lần đăng nhập sql. Một cho quyền truy cập lớp thông qua SP (quyền chỉ thực thi) và một cho mô-đun linq logic cho phép truy cập bảng trực tiếp.

Lựa chọn giữa ORM theo mức độ phổ biến không phải là điều tốt nhất nên làm. Tôi đã cố gắng chuyển sang EF trong 2 năm qua và tất cả những gì tôi có thể nói là, tại sao tôi vẫn cố gắng?

ATM quan điểm của tôi về EF là: "Nó được tạo ra cho các hệ thống bit cực kỳ nhỏ xinh với không quá 3 bảng với ít hơn 1 mối quan hệ (0 thì tốt hơn)".

Và tại sao tôi lại nghĩ như vậy? 1. Cố gắng cập nhật một đồ thị bị ngắt kết nối và xem mô hình của bạn bị xước;

1. Cố gắng tạo TPH với các cây kế thừa sâu sắc và bạn sẽ thấy rằng bạn đang bị phân chia thành một hệ thống phân cấp duy nhất hoặc hệ thống sẽ bị hỏng.

2. Cố gắng thực hiện các câu truy vấn rườm rà hơn và xem toàn bộ hệ thống ăn hết stack: D ... tràn xảy ra rất thường xuyên.

3. Các kiểu dữ liệu của Map XML dựa trên các phần mở rộng hoặc các thuộc tính NotMapped "bị ghét" nhất ... và nó thậm chí còn tệ hơn.

4. Hãy thử trộn truy vấn SQL vào Linq để có nhiều truy vấn finner hơn và bạn sẽ phá vỡ bức tường lol.

5. Và điều cuối cùng và quan trọng nhất, EF không hỗ trợ công thức thuộc tính ('một tài nguyên tuyệt vời mà NH có cho cơ sở dữ liệu kế thừa') và không hỗ trợ ánh xạ kiểu phức tạp cho cùng một bảng và các bảng có liên quan.

Đó là 10cc của tôi.