Hibernate hoặc JPA hoặc JDBC hoặc?

Question

Tôi đang phát triển một ứng dụng Java Desktop nhưng có một số nhầm lẫn trong việc lựa chọn một công nghệ cho lớp kiên trì của tôi.

Cho đến bây giờ, tôi đã sử dụng JDBC cho các hoạt động DB. Bây giờ, Gần đây tôi đã học Hibernate và JPA nhưng tôi vẫn là người mới làm quen với những công nghệ này.

Bây giờ câu hỏi của tôi là gì để sử dụng cho ứng dụng Java Desktop của tôi sau đây?

• JPA

• Hibernate

• JDBC

• DAO

• bất cứ đề nghị khác từ bạn ...

Tôi biết rằng không có sự lựa chọn tốt nhất từ ​​họ và nó hoàn toàn phụ thuộc vào sự phức tạp và requeirements của dự án nên dưới đây là những yêu cầu của dự án của tôi

1. Nó không phải là một ứng dụng phức tạp. Nó chỉ chứa 5 bảng (và 5 thực thể)
2. Tôi không thể làm cho mã của mình linh hoạt để tôi có thể thay đổi cơ sở dữ liệu sau một cách dễ dàng
3. Kích thước của ứng dụng sẽ càng nhỏ càng tốt vì tôi sẽ phải phân phối nó cho khách hàng của tôi thông qua internet.
4. Nó phải được sử dụng miễn phí trong phát triển và phân phối thương mại.

==================================== EDITED ======= ================================

Trên cơ sở các câu trả lời dưới đây, tôi muốn đi với JPA để ngăn bản thân tôi viết mã SQL của nhà cung cấp cụ thể.

Nhưng tôi có một số vấn đề trong JPA được nêu tại Java Persistence API

Answer 1

Đối với bất cứ điều gì quy mô này sẽ làm việc Allright. Xem xét iBatis.

Answer 2

Dưới đây là quan điểm của tôi:

• JPA: cách Agnostic làm Java kiên trì mà không ghép khách hàng của bạn để Hibernate, TopLink vv
• Hibernate: Tốt lựa chọn nếu bạn có một mô hình đối tượng để ánh xạ.
• JDBC: Tất cả sự kiên trì của Java được xây dựng dựa trên điều này. Mức thấp nhất
• DAO: Nhiều mô hình hơn công nghệ; Giao diện hoạt động CRUD.
• iBatis: Nửa đường giữa JDBC (SQL nguyên) và Hibernate (ORM).
• JDO: Các đối tượng dữ liệu Java, là một đặc điểm kỹ thuật khác cho sự kiên trì Java. (ví dụ., Apache JDO)

Nó không phải là một ứng dụng phức tạp. Nó chỉ chứa 5 bảng (và 5 pháp nhân)

Bất kỳ điều nào trong số này đều hiệu quả, nhưng JDBC sẽ đơn giản nhất. Tất cả những thứ khác được xây dựng trên JDBC.

Tôi muốn làm cho mã của tôi linh hoạt để tôi có thể thay đổi cơ sở dữ liệu sau dễ dàng

thay đổi Schema sẽ có tác dụng tương tự trong tất cả các công nghệ.

Kích thước của ứng dụng sẽ càng nhỏ càng tốt vì tôi sẽ phải phân phối cho khách hàng thông qua internet.

Sử dụng JPA hoặc Hibernate sẽ yêu cầu các JAR sẽ thêm vào kích thước triển khai của bạn. JDBC sẽ giảm thiểu điều này.

Nó phải được sử dụng miễn phí trong phát triển và phân phối thương mại.

Xem giấy phép của tất cả các công nghệ. Không nên là một vấn đề với bất kỳ người trong số họ.

FYI: Có thể viết một giao diện DAO chung:

package persistence; 

import java.io.Serializable; 
import java.util.List; 

public interface GenericDao<T, K extends Serializable> 
{ 
    T find(K id); 
    List<T> find(); 
    List<T> find(T example); 
    List<T> find(String queryName, String [] paramNames, Object [] bindValues); 

    K save(T instance); 
    void update(T instance); 
    void delete(T instance); 
} 

Nếu đối tượng của bạn lập bản đồ 1: 1 với năm bảng của bạn, tôi muốn nói rằng JPA là overkill phương.

Ứng dụng của bạn hiện có theo thứ tự 3MB JAR không? Nếu không, thì Hibernate hoặc JPA sẽ tăng hơn gấp đôi kích thước. Bạn có thể định lượng chính xác bao nhiêu. Và có nhiều hơn một JAR, bởi vì cả hai đều có phụ thuộc.

YAGNI nói rằng bạn nên giữ đơn giản. Đó là năm bàn!

Thay đổi nhà cung cấp, nếu bạn làm đúng, nghĩa là chuyển JAR trình điều khiển JDBC, thay đổi tên lớp trình điều khiển và thêm URL kết nối mới - bạn phải làm gì dù bạn chọn công nghệ nào.

Tôi thấy rằng cơ sở dữ liệu không thay đổi triệt để. Bạn sẽ thay đổi giản đồ, nhưng toàn bộ nhà cung cấp? Không có khả năng, đặc biệt nếu bạn có nhiều khách hàng. Nó sẽ là một sự bất tiện lớn để tạo cơ sở dữ liệu chuyển đổi cơ sở người dùng.

Bạn đang định giao hàng với ai? HSQL hoặc cái gì đó sẽ yêu cầu một cài đặt như MySQL? Đó là một mối quan tâm thích hợp hơn.

Answer 3

JPA chắc chắn là cách để đi là bạn muốn sử dụng ánh xạ đối tượng đối tượng - đó là triển khai thực thể (nghĩa là bạn có thể sử dụng nó với Hibernate, Toplink, v.v.) và đó là chuẩn thực tế. Hibernate có một bộ tính năng phong phú hơn, nhưng đây là một giải pháp không chuẩn - nhiều người sử dụng nó mặc dù ... Cá nhân tôi luôn sử dụng JPA được hỗ trợ bởi Hibernate. Tôi cố gắng tránh xa những thứ cụ thể ngủ đông, nhưng nếu cần - nó ở đó cho tôi.

Sử dụng khung làm việc như JPA/Hibernate cho 5 bảng có thể là một chút quá mức cần thiết. Ứng dụng của bạn sẽ lớn hơn khoảng 5MB và sẽ tiêu hao nhiều bộ nhớ hơn. Bạn có thể chỉ cần chọn sử dụng JDBC được ghép nối với DAO.

Vì JDBC sử dụng SQL là nhà cung cấp (cơ sở dữ liệu) cụ thể, điều này có thể có vấn đề là bạn đang lên kế hoạch sử dụng các cơ sở dữ liệu khác nhau. JPA có lợi thế rõ ràng trong lĩnh vực này. Bất cứ điều gì bạn chọn bạn không thể đi sai - bạn cần phải tự hỏi mình chủ yếu là tăng kích thước và tiêu thụ bộ nhớ một vấn đề và bạn có sẵn sàng để viết mã JDBC boilerplate DAO. Tôi thường ghét điều này :-)