Ưu điểm và nhược điểm chính của NHibernate và Entity Framework 4.0 là gì?Quyết định giữa NHibernate vs Entity Framework?
(khi gắn thẻ câu hỏi của tôi, tôi đã nhận thấy nhiều thẻ NHibernate hơn Is NHibernate EF. Phổ biến hơn?)
Tôi đã có rất ít kinh nghiệm với EF (một vài bài đăng trên blog và hướng dẫn), nhưng có nhiều trải nghiệm với NHibernate.
Microsoft luôn ở phía sau nơi phong trào OpenSource là, và điều này chắc chắn là trường hợp với NHibernate. Khi EF 1.0 được phát hành lần đầu, nó thiếu hỗ trợ cho các tính năng chính như hỗ trợ POCO và sự thiếu hiểu biết, nó yêu cầu các lớp thực thể của bạn mở rộng một lớp thực thể cơ bản từ EF, vì vậy các lớp thực thể của bạn không hoàn toàn tách rời khỏi EF. Khả năng bảo trì và khả năng kiểm tra đơn vị này cũng như khả năng chuyển đổi các nhà cung cấp ORM nếu cần.
NHibernate mặt khác cho phép bạn tách hoàn toàn các thực thể của bạn khỏi chính NHibernate. EF 4.0 đã bắt kịp một phần trong vấn đề này, đó là cách tiếp cận Mã đầu tiên phát triển (recently announce by Scott Guthrie) là một bước đi đúng hướng.
Bản thân NHibernate có một số khả năng ánh xạ rất mạnh như ánh xạ thừa kế, ánh xạ các lớp thành phần (xem đối tượng Address trên thực thể Customer), ánh xạ liên kết thực thể đơn hướng. Nó cho phép bạn tận dụng toàn bộ sức mạnh của lập trình hướng đối tượng (đóng gói, đa hình, thừa kế, vv) bên trong mô hình miền của bạn, nghĩ về các lớp thực thể của bạn như là hành vi đóng gói và không chỉ các thùng chứa dữ liệu. Nếu bạn đang mong muốn xây dựng mô hình miền của mình theo nguyên tắc Domain Driven Design, thì NHibernate phù hợp với điều này. Tôi không thể nói trực tiếp trên EF 4.0 trên những điểm này, chỉ từ những gì tôi nghe từ những người dùng NHibernate khác đang cố gắng sử dụng EF 4.0, nhưng EF 4.0 vẫn tụt lại phía sau trong những lĩnh vực này, nhưng nó đang tăng lên.
Tôi muốn nói sự thật rằng Entity Framework là từ Microsoft vừa là một lợi thế và bất lợi. Bạn đang nhận được một khuôn khổ ngay từ cùng một nguồn với .NET. Tin xấu là Microsoft thường xuyên bị lỗi cơ sở mã của riêng mình mà không quan tâm đến khả năng tương thích ngược.
NHibernate không đến từ Microsoft và không có tiêu chuẩn nào khác với những gì nhà phát triển Hibernate và NHibernate nói thuộc về mã của họ. Tin tốt là họ thường chú ý đến khả năng tương thích ngược. Có một cơ sở người dùng lớn, bởi vì Hibernate đã được khoảng một thời gian.
Một trong những tính năng tôi thích nhất về Mùa xuân là họ không đưa ra quyết định như thế này cách xa bạn. Spring có các tính năng JDBC riêng, nhưng nó hỗ trợ Hibernate, TopLink, JDO, iBatis và JPA. Bạn cũng được tự do tiêm các lớp của riêng mình nếu bạn quyết định đi theo một cách khác (ví dụ: NoSQL). Tại sao lựa chọn của bạn phải được quyết định bởi sự lựa chọn khung? Nó rất nanny-ish: "Chúng tôi là Microsoft, chúng tôi biết những gì tốt nhất cho bạn tốt hơn bạn."
Cảm ơn bạn đã làm cho nó rõ ràng từ một quan điểm hoàn toàn phi kỹ thuật. NHibernate có vẻ giống như một trận đấu tốt với ASP.NET MVC, là cả hai sản phẩm là rất mã nguồn mở. –
Bất cứ ai nói với bạn rằng EF 4 yêu cầu viết lại đã không thực sự thử nó. Tôi vừa cập nhật một dự án lớn EF 1 lên .NET 4 (vì vậy không chỉ thay đổi EF, mà là trình cài đặt, FxCop, v.v.) trong chưa đầy một ngày. Vì lý do nào đó, trải nghiệm thực tế với EF dường như không phải là điều kiện tiên quyết để thể hiện ý kiến của một người về nó. –
Nhận nó từ một đồng nghiệp mà tôi nghĩ là hiểu biết. Có lẽ tôi đã hiểu lầm. Tôi sẽ chỉnh sửa câu trả lời. – duffymo
Câu hỏi hay. Rất thích hợp với nhiều người trong chúng ta. Tôi sẽ xem câu trả lời này cho những người có nhiều kinh nghiệm hơn với cả hai. –
Tôi rất tò mò về yêu cầu của bạn là gì và bạn đã chọn lựa như thế nào cho hai lựa chọn này so với các tùy chọn khác. Bất kỳ suy nghĩ về LINQ to SQL hoặc iBATIS.NET? Chỉ cần ném nó ra khỏi đó: http://stackoverflow.com/questions/694552/what-is-the-difference-between-nhibernate-and-ibatis-net –
LINQ to SQL là một sản phẩm đã chết. iBatis được thiết kế xung quanh procs được lưu trữ. –