Hibernate vs JPA vs JDO - ưu và nhược điểm của từng loại? [đóng cửa]

Tôi quen thuộc với ORM như một khái niệm và thậm chí tôi đã sử dụng nHibernate vài năm trước cho một dự án .NET; tuy nhiên, tôi không theo kịp chủ đề ORM trong Java và chưa có cơ hội sử dụng bất kỳ công cụ nào trong số này.

Nhưng, bây giờ tôi có thể có cơ hội bắt đầu sử dụng một số công cụ ORM cho một trong các ứng dụng của chúng tôi, trong nỗ lực tránh xa hàng loạt dịch vụ web cũ.

Tôi đang gặp khó khăn khi nói về sự khác biệt giữa các thông số JPA, những gì bạn nhận được với chính thư viện Hibernate và những gì JDO cung cấp.

Vì vậy, tôi hiểu rằng câu hỏi này hơi mở, nhưng tôi đã hy vọng nhận được một số ý kiến ​​về:

• Những ưu và nhược điểm của mỗi là gì?
• Mà bạn sẽ đề nghị cho một dự án mới?
• Có những điều kiện nhất định khi sử dụng một khung so với khung kia có ý nghĩa không?

Một số lưu ý:

• JDO và JPA đều là thông số kỹ thuật, không triển khai.
• Ý tưởng là bạn có thể trao đổi các triển khai JPA, nếu bạn hạn chế mã của mình chỉ sử dụng JPA tiêu chuẩn. (Ditto cho JDO.)
• Hibernate có thể được sử dụng như một cách triển khai JPA như vậy.
• Tuy nhiên, Hibernate cung cấp API gốc, với các tính năng trên và vượt xa so với JPA.

IMO, tôi muốn giới thiệu Hibernate.

Đã có một số ý kiến ​​/ câu hỏi về những gì bạn nên làm nếu bạn cần sử dụng các tính năng dành riêng cho Hibernate. Có nhiều cách để xem xét điều này, nhưng lời khuyên của tôi sẽ là:

• Nếu bạn không lo lắng về triển vọng liên kết của nhà cung cấp, thì hãy lựa chọn giữa Hibernate và các triển khai JPA và JDO khác bao gồm các phần mở rộng cụ thể của nhà cung cấp trong quá trình ra quyết định của bạn.

• Nếu bạn lo lắng về triển vọng liên kết của nhà cung cấp và bạn không thể sử dụng JPA mà không dùng đến các tiện ích mở rộng cụ thể của nhà cung cấp, thì đừng sử dụng JPA. (Ditto cho JDO).

Trong thực tế, có lẽ bạn sẽ cần phải đánh đổi mức độ lo lắng của nhà cung cấp so với mức độ bạn cần những tiện ích mở rộng cụ thể của nhà cung cấp đó.

Và cũng có những yếu tố khác, như bạn / nhân viên của bạn biết rõ các công nghệ tương ứng như thế nào, sản phẩm sẽ có giá bao nhiêu khi cấp phép và câu chuyện mà bạn tin về những gì sẽ xảy ra trong tương lai cho JDO và JPA.

Hãy chắc chắn rằng bạn đánh giá việc triển khai DataNucleus của JDO. Chúng tôi bắt đầu với Hibernate vì nó dường như rất phổ biến nhưng khá sớm nhận ra rằng đó không phải là một giải pháp bền bỉ minh bạch 100%. Có quá nhiều cảnh báo và tài liệu đầy 'nếu bạn gặp tình huống này thì bạn phải viết mã của mình như thế này', điều đó đã lấy đi niềm vui của việc tự do mô hình hóa và mã hóa theo cách chúng tôi muốn. JDO chưa bao giờ khiến tôi phải điều chỉnh mã hoặc mô hình của mình để làm cho nó hoạt động bình thường '. Tôi chỉ có thể thiết kế và mã hóa các POJO đơn giản như thể tôi sẽ chỉ sử dụng chúng 'trong bộ nhớ', nhưng tôi có thể duy trì chúng trong suốt.

Ưu điểm khác của JDO / DataNucleus so với ngủ đông là nó không có chi phí phản ánh thời gian chạy và hiệu quả bộ nhớ cao hơn vì nó sử dụng tăng cường mã byte thời gian xây dựng (có thể thêm 1 giây vào thời gian xây dựng của bạn cho một dự án lớn) hơn mô hình proxy hỗ trợ phản xạ thời gian chạy của hibernate.

Một điều khác mà bạn có thể thấy khó chịu với Hibernate là một tài liệu tham khảo mà bạn có về những gì bạn nghĩ là đối tượng ... nó thường là 'proxy' cho đối tượng. Không có lợi ích của việc tăng cường mã byte, mẫu proxy được yêu cầu để cho phép tải theo yêu cầu (nghĩa là tránh kéo toàn bộ biểu đồ đối tượng của bạn khi bạn kéo vào một đối tượng cấp cao nhất). Hãy chuẩn bị để ghi đè bằng và mã băm vì đối tượng bạn nghĩ bạn đang tham khảo thường chỉ là proxy cho đối tượng đó.

Đây là một ví dụ về sự thất vọng bạn sẽ nhận được với Hibernate mà bạn sẽ không nhận được với JDO:

http://blog.andrewbeacock.com/2008/08/how-to-im
vây-hibernate-safe-equals.html http://burtbeckwith.com/blog/?p=53

Nếu bạn thích mã hóa thành 'cách giải quyết' thì chắc chắn, Hibernate là dành cho bạn. Nếu bạn đánh giá cao sự phát triển theo hướng mô hình, sạch, hướng đối tượng, trong đó bạn dành toàn bộ thời gian cho mô hình hóa, thiết kế và mã hóa và không có gì trong các cách giải quyết xấu xí thì hãy dành vài giờ để đánh giá JDO / DataNucleus . Số giờ đầu tư sẽ được hoàn trả gấp ngàn lần.

Cập nhật tháng 2 năm 2017

Đã khá lâu rồi DataNucleus 'triển khai tiêu chuẩn duy trì JPA bên cạnh tiêu chuẩn kiên trì JDO, do đó, việc chuyển các dự án JPA hiện tại từ Hibernate sang DataNucleus sẽ rất đơn giản và bạn có thể nhận được tất cả các lợi ích được đề cập ở trên của DataNucleus , nếu có. Vì vậy, về mặt câu hỏi, việc lựa chọn một tiêu chuẩn cụ thể, JPA (chỉ RDBMS) so với JDO (RDBMS + Không SQL + ODBMSes + khác), DataNucleus hỗ trợ cả hai, Hibernate chỉ bị giới hạn ở JPA.

Hiệu suất cập nhật DB Hibernate

Một vấn đề khác cần xem xét khi chọn ORM là hiệu quả của cơ chế kiểm tra bẩn của nó - trở nên rất quan trọng khi cần xây dựng SQL để cập nhật các đối tượng đã thay đổi trong giao dịch hiện tại - đặc biệt là khi có nhiều đối tượng. Có một mô tả kỹ thuật chi tiết về cơ chế kiểm tra bẩn của Hibernate trong câu trả lời SO này: JPA với HIBERNATE chèn rất chậm

Gần đây tôi đã đánh giá và chọn một khung kiên trì cho một dự án java và kết quả của tôi như sau:

Những gì tôi đang thấy là sự hỗ trợ có lợi cho JDO chủ yếu là:

• bạn có thể sử dụng các nguồn dữ liệu không phải là sql, db4o, hbase, ldap, bigtable, couchdb (plugin cho cassandra), v.v.
• bạn có thể dễ dàng chuyển từ nguồn dữ liệu sql sang nguồn dữ liệu không phải sql và ngược lại.
• không có đối tượng proxy và do đó ít đau hơn đối với việc triển khai hashcode () và bằng ()
• POJO nhiều hơn và do đó cần ít cách giải quyết hơn
• hỗ trợ nhiều mối quan hệ và loại trường

và sự hỗ trợ có lợi cho JPA là chủ yếu:

• phổ biến hơn
• jdo đã chết
• không sử dụng tăng cường mã byte

Tôi đang thấy rất nhiều bài viết ủng hộ JPA từ các nhà phát triển JPA, những người rõ ràng không sử dụng JDO / Datanucleus cung cấp các đối số yếu cho việc không sử dụng JDO.

Tôi cũng đang thấy rất nhiều bài đăng từ người dùng JDO đã di chuyển sang JDO và kết quả là hạnh phúc hơn nhiều.

Đối với JPA là phổ biến hơn, có vẻ như điều này một phần là do sự hỗ trợ của nhà cung cấp RDBMS chứ không phải là nó vượt trội về mặt kỹ thuật. (Âm thanh như VHS / Betamax với tôi).

JDO và triển khai tham chiếu của nó Datanucleus rõ ràng không chết, như được thể hiện bằng việc áp dụng nó cho GAE và phát triển tích cực trên mã nguồn (http://sourceforge.net/projects/datanucleus/).

Tôi đã thấy một số khiếu nại về JDO do tăng cường mã byte, nhưng chưa có lời giải thích nào cho lý do tại sao nó xấu.

Trong thực tế, trong một thế giới ngày càng bị ám ảnh bởi các giải pháp NoQuery, JDO (và việc triển khai datanucleus) dường như an toàn hơn nhiều.

Tôi mới bắt đầu sử dụng JDO / Datanucleus và đã thiết lập nó để tôi có thể dễ dàng chuyển đổi giữa việc sử dụng db4o và mysql. Thật hữu ích cho việc phát triển nhanh để sử dụng db4o và không phải lo lắng quá nhiều về lược đồ DB và sau đó, khi lược đồ được ổn định để triển khai vào cơ sở dữ liệu. Tôi cũng cảm thấy tự tin rằng sau này, tôi có thể triển khai tất cả / một phần ứng dụng của mình lên GAE hoặc tận dụng lưu trữ phân tán / giảm bản đồ một la hbase / hadoop / cassandra mà không cần tái cấu trúc quá nhiều.

Tôi thấy trở ngại ban đầu khi bắt đầu với Datanucleus hơi khó khăn - Tài liệu trên trang web datanucleus hơi khó để vào - các hướng dẫn không dễ thực hiện như tôi muốn. Phải nói rằng, tài liệu chi tiết hơn về API và ánh xạ là rất tốt khi bạn vượt qua giai đoạn học tập ban đầu.

Câu trả lời là, nó phụ thuộc vào những gì bạn muốn. Tôi thà có mã sạch hơn, không có nhà cung cấp khóa, định hướng pojo hơn, các tùy chọn nosql phổ biến hơn.

Nếu bạn muốn cảm giác ấm áp cầu kỳ mà bạn đang làm giống như phần lớn các nhà phát triển / cừu khác, hãy chọn JPA / hibernate. Nếu bạn muốn dẫn đầu trong lĩnh vực của mình, hãy lái thử JDO / Datanucleus và làm cho tâm trí của bạn lên.

Mà bạn sẽ đề nghị cho một dự án mới?

Tôi cũng không đề nghị! Sử dụng Spring DAO JdbcTemplatecùng với StoredProcedure, RowMappervà RowCallbackHandlerthay vào đó.

Kinh nghiệm cá nhân của tôi với Hibernate là thời gian lưu trước được bù đắp nhiều hơn bởi những ngày bất tận bạn sẽ dành hết thời gian để cố gắng hiểu và gỡ lỗi các vấn đề như hành vi cập nhật xếp tầng bất ngờ.

Nếu bạn đang sử dụng một DB quan hệ thì mã của bạn càng gần nó, bạn càng có nhiều quyền kiểm soát. Lớp DAO của Spring cho phép kiểm soát tốt lớp ánh xạ, đồng thời loại bỏ sự cần thiết của mã soạn sẵn. Ngoài ra, nó tích hợp vào lớp giao dịch của Spring, điều đó có nghĩa là bạn có thể dễ dàng thêm (thông qua AOP) hành vi giao dịch phức tạp mà không xâm nhập vào mã của bạn (tất nhiên, bạn cũng nhận được điều này với Hibernate).

JDO đã chết

JDO không thực sự chết vì vậy hãy kiểm tra sự thật của bạn. JDO 2.2 được phát hành vào tháng 10 năm 2008 JDO 2.3 đang được phát triển.

Điều này được phát triển công khai, dưới Apache. Nhiều bản phát hành hơn JPA đã có, và đặc điểm kỹ thuật ORM của nó vẫn đi trước cả các tính năng được đề xuất của JPA2

JDO đang có các tính năng nâng cao hơn JPA, hãy xem http://db.apache.org/jdo/jdo_v_jpa.html

Tôi đang sử dụng JPA (triển khai OpenJPA từ Apache, dựa trên cơ sở mã KODO JDO đã hơn 5 năm tuổi và cực kỳ nhanh / đáng tin cậy). IMHO bất cứ ai nói với bạn bỏ qua các thông số kỹ thuật là cho bạn lời khuyên tồi. Tôi đặt thời gian vào và chắc chắn đã được khen thưởng. Với JDO hoặc JPA, bạn có thể thay đổi nhà cung cấp với các thay đổi tối thiểu (JPA có ánh xạ orm để chúng tôi nói chuyện ít hơn một ngày để có thể thay đổi nhà cung cấp). Nếu bạn có hơn 100 bảng như tôi thì điều này là rất lớn. Thêm vào đó, bạn nhận được bộ nhớ đệm dựng sẵn với các lần xóa bộ nhớ cache theo cụm và tất cả đều tốt. SQL / Jdbc tốt cho các truy vấn hiệu suất cao nhưng tính bền bỉ trong suốt vượt trội hơn nhiều so với việc viết các thuật toán và thói quen nhập dữ liệu của bạn. Tôi chỉ có khoảng 16 truy vấn SQL trong toàn bộ hệ thống của mình (50k + dòng mã).

Tôi đã tự mình xem xét vấn đề này và không thể tìm thấy sự khác biệt mạnh mẽ giữa hai điều này. Tôi nghĩ rằng sự lựa chọn lớn là trong đó bạn sử dụng thực hiện. Đối với bản thân tôi, tôi đã xem xét nền tảng DataNucleus vì đây là một triển khai bất khả tri lưu trữ dữ liệu của cả hai.

Bất cứ ai nói rằng JDO đã chết là một người mong muốn FUD lướt sóng và họ biết điều đó.

JDO vẫn còn sống và tốt. Đặc điểm kỹ thuật vẫn mạnh mẽ, trưởng thành và tiên tiến hơn so với JPA trẻ hơn và bị hạn chế.

Nếu bạn muốn giới hạn bản thân mình chỉ những gì có sẵn trong tiêu chuẩn JPA, bạn có thể viết thư cho JPA và sử dụng DataNucleus như một triển khai bền bỉ, minh bạch hơn so với các triển khai khác của JPA. Tất nhiên DataNucleus cũng thực hiện tiêu chuẩn JDO nếu bạn muốn tính linh hoạt và hiệu quả của việc mô hình hóa mà JDO mang lại.

Tôi đã sử dụng Hibernate (triển khai JPA) và JPOX (triển khai JDO) trong cùng một dự án. JPOX hoạt động tốt, nhưng gặp phải lỗi khá nhanh, ở đó một số tính năng ngôn ngữ Java 5 không hỗ trợ tại thời điểm đó. Nó có vấn đề khi chơi tốt với các giao dịch XA. Tôi đã tạo ra lược đồ cơ sở dữ liệu từ các đối tượng JDO. Nó muốn kết nối với cơ sở dữ liệu mỗi lần gây phiền nhiễu nếu kết nối Oracle của bạn không hoạt động.

Sau đó chúng tôi chuyển sang Hibernate. Chúng tôi đã đùa giỡn với việc chỉ sử dụng JPA thuần túy trong một thời gian, nhưng chúng tôi cần sử dụng một số tính năng cụ thể của Hibernate để thực hiện ánh xạ. Chạy cùng một mã trên nhiều cơ sở dữ liệu là rất dễ dàng. Hibernate dường như lưu trữ các đối tượng mạnh mẽ hoặc đôi khi có hành vi bộ đệm lạ. Có một số cấu trúc DDL mà Hibernate không thể xử lý và do đó chúng được xác định trong một tệp bổ sung được chạy để khởi tạo cơ sở dữ liệu. Khi tôi gặp phải vấn đề Hibernate, thường có nhiều người gặp phải vấn đề tương tự, điều này khiến cho việc tìm kiếm giải pháp trở nên dễ dàng hơn. Cuối cùng, Hibernate dường như được thiết kế tốt và đáng tin cậy.

Một số người trả lời khác đã đề nghị chỉ sử dụng SQL. Trường hợp sử dụng sát thủ thực sự cho ánh xạ quan hệ đối tượng là thử nghiệm và phát triển. Các cơ sở dữ liệu được xây dựng để xử lý khối lượng dữ liệu lớn thường đắt tiền và hoặc chúng khó cài đặt. Họ rất khó để kiểm tra với. Có rất nhiều cơ sở dữ liệu Java trong bộ nhớ có thể được sử dụng để kiểm tra, nhưng thường vô dụng đối với sản xuất. Có thể sử dụng một cơ sở dữ liệu thực, nhưng có giới hạn, sẽ tăng năng suất phát triển và độ tin cậy của mã.

Tôi đã tạo một WebApp mẫu vào tháng 5 năm 2012 sử dụng JDO 3.0 & DataNucleus 3.0 - hãy xem nó sạch như thế nào: https://github.com/TorbenVesterager/BadAssWebApp

Có thể nó hơi quá sạch sẽ, vì tôi sử dụng cả POJO cho cơ sở dữ liệu và ứng dụng khách JSON, nhưng điều đó thật thú vị :)

PS: Chứa một vài chú thích SuppressWarnings (được phát triển trong IntelliJ 11)