JPA vs Spring JdbcTemplate

Question

Đối với một dự án mới, JPA luôn là công cụ được đề xuất để xử lý dữ liệu quan hệ hoặc có các tình huống trong đó Spring JdbcTemplate là một lựa chọn tốt hơn không? Một số yếu tố cần xem xét trong phản ứng của bạn:

• schema cơ sở dữ liệu mới vs tồn tại trước đó lược đồ và bảng
• mức độ chuyên môn phát triển
• dễ dàng mà có thể tích hợp với một lớp dữ liệu bộ nhớ đệm
• hiệu suất
• bất kỳ yếu tố nào khác có liên quan để xem xét?

Answer 1

Sử dụng Spring JdbcTemplate nếu bạn không muốn truy cập giản đồ cơ sở dữ liệu của mình thông qua mô hình miền. Sử dụng JdbcTemplate bạn đang sử dụng một truy cập cấp thấp hơn, với sự linh hoạt hơn, nhưng có lẽ cũng có nhiều bản mẫu.

Spring JdbcTemplate có thể dễ dàng được sử dụng với các lược đồ cơ sở dữ liệu kỳ lạ và tập trung thủ tục lưu trữ. Sử dụng JPA bạn cần đảm bảo rằng lược đồ cơ sở dữ liệu ánh xạ chính xác đến mô hình miền.

Cả hai công nghệ đều cần nhà phát triển biết cơ sở dữ liệu quan hệ, SQL và giao dịch. Với JPA, bạn sẽ có được sự phức tạp ẩn hơn.

JPA là kiến ​​thức của tôi dễ dàng cắm thêm vào các lớp bộ nhớ đệm dữ liệu, vì tiêu điểm hướng đối tượng giúp xác định mục nhập bộ nhớ cache, cập nhật và vô hiệu dễ dàng hơn.

Bạn có thể tinh chỉnh các phần phụ trợ dựa trên JdbcTemplate tốt hơn, nhưng có nhiều trường hợp liên quan đến mã hơn.

Một số khía cạnh khác cần xem xét là mặc dù với JPA bạn nhận được một mô hình miền cho lược đồ cơ sở dữ liệu của bạn, bạn thường sẽ cần phải sử dụng các lớp DTO bổ sung. Sử dụng JdbcTemplate bạn có thể trực tiếp hoạt động với các lớp DTO.

Answer 2

Tôi đồng ý với @Timo. Chỉ có cái nhìn sâu sắc khác tôi sẽ thêm/mở rộng là ORM có ngữ nghĩa khác nhau từ truy cập sql thuần túy vào dữ liệu của bạn.

Điểm ORM là trừu tượng hóa thực tế là dữ liệu của bạn nằm trong một DB, càng nhiều càng tốt. Khi bạn sử dụng ORM đúng cách, tất cả các hoạt động liên tục được xử lý trong một lớp mỏng (hy vọng). Các đối tượng mô hình của bạn sẽ có ít hoặc không có mã kiên trì; thực tế là bạn đang sử dụng ORM nên ẩn với mô hình của bạn.

Vì lý do này, ORM rất tốt trong việc giúp cuộc sống của bạn trở nên dễ dàng đối với một số loại hoạt động nhất định, cụ thể là các hoạt động CRUD đơn giản. Bạn có thể tải các đối tượng mô hình của bạn, trình bày chúng, cập nhật chúng, xóa chúng khá dễ dàng. Nó làm cho cuộc sống của bạn dễ dàng hơn bởi vì khi bạn truy cập dữ liệu của mình, bạn sẽ lấy lại các đối tượng mô hình, trên đó bạn có thể viết logic nghiệp vụ. Nếu bạn sử dụng JDBC, bạn sẽ phải 'hydrate' đối tượng của bạn từ dữ liệu, có thể phức tạp và dễ bị lỗi.

ORM không phải lúc nào cũng là lựa chọn tốt nhất. JPA là một công cụ cho một công việc, nếu công cụ này không đủ cho công việc bạn sẽ muốn tìm một công cụ tốt hơn. Ví dụ, tôi đã có một kịch bản mà tôi đã phải sao chép toàn bộ đồ thị đối tượng và lưu một bản sao mới của các đối tượng đó. Nếu tôi đã sử dụng ORM (như tôi đã cố gắng làm), tôi phải tải tất cả các đối tượng ra khỏi DB, sau đó sao chép chúng, sau đó lưu các đối tượng mới. Tôi đã mất quá nhiều thời gian.

Giải pháp tốt hơn chỉ đơn giản là sử dụng các hoạt động dựa trên jdbc và 'chèn qua chọn' các cuộc gọi sql để tạo các hàng mới. Nó nhanh, mã đơn giản hơn.

Điều khác cần lưu ý là bạn cảm thấy thoải mái với JDBC và có thời hạn, bạn không cần phải nhảy vào băng tần ORM. Các lớp Spring JdbcTemplate cực kỳ mạnh mẽ và hữu ích. Đôi khi công cụ tốt nhất cho công việc là công cụ bạn biết. Bạn nên tự làm quen với ORM, nhưng không nhất thiết cho một dự án có kỳ vọng cao. Có rất nhiều thứ để tìm hiểu và nó không tầm thường - thực sự bạn đang giao dịch một bộ phức tạp với nhau trong sự lựa chọn để sử dụng jdbc vs orm.

Answer 3

Tôi hơi muộn bài đăng này, nhưng tôi có xu hướng sử dụng JdbcTemplate trên ORM. Tôi biết SQL (khá tốt) và thực sự không muốn bị "trừu tượng hóa" khỏi DB của tôi. Tôi thấy hầu hết thời gian, ứng dụng của tôi đang sử dụng chế độ xem DB, nơi tôi đẩy hầu hết logic nghiệp vụ lên tới. Tôi đã DAO lớp lớp đúng có triển khai JdbcTemplate. Nó cảm thấy "sạch" và hầu hết các mã boilerplate được ẩn bởi JdbcTemplate (và nó là tài liệu trực tuyến dường như MUCH tốt hơn sau đó ORM stuff). Thời gian giới hạn tôi đã sử dụng một cái gì đó như Hibernate, tôi tìm thấy khi nó làm việc, nó tiết kiệm cho tôi một thời gian ... nhưng khi nó đã không hoạt động đúng, nó chi phí cho tôi ngày của "WTF" gỡ lỗi. Tôi đã không bao giờ phải chi tiêu nhiều hơn sau đó 20 phút gỡ lỗi JdbcTemplate DAO impls. Tôi nghĩ rằng chìa khóa, như những người khác đã lưu ý, là mức độ thoải mái của bạn với thiết kế SQL/Schema

Answer 4

Nó không được đề cập trong các câu trả lời khác nhưng nó là tốt để sử dụng cả hai. Trong ứng dụng của tôi, tôi sử dụng JPA và JdbcTemplate, đối với các hoạt động kiểu crud tôi sử dụng JPA nhưng để báo cáo hoặc ở đâu nó dễ dàng hơn tôi sử dụng jdbcTemplate.

@Repository 
public class FooRepository 
{ 
    @PersistenceContext 
    private EntityManager entityManager; 

    @Autowired(required = true) 
    private JdbcTemplate jdbcTemplate; 

    public void saveFoo(Foo foo) 
    { 
     this.entityManager.persist(foo); 
    } 

    public List<SomeReportPojo> getSomeReport() 
    { 
     return this.entityManager.queryForList("SELECT .. ",SomeProjectPojo.class); 
    } 
} 

Điều tuyệt vời về Spring là ngoại lệ dịch từ ngoại lệ JPA sang phân cấp ngoại lệ mùa xuân Dao hoạt động với cả JPA và jdbcTemplate. Vì vậy, sử dụng JPA khi nó có ý nghĩa và jdbcTemplate khi nó có ý nghĩa.

Answer 5

Tại nơi làm việc, chúng tôi sử dụng Hibernate JDBCTemplate vì nó linh hoạt hơn. Nó cũng có hiệu suất tốt hơn so với JPA vì bạn không "tải" nhiều dữ liệu không cần thiết vào ứng dụng của mình.
Trong trường hợp JDBCTemplate, kỹ năng SQL của bạn đi một chặng đường dài trong việc cung cấp cho bạn chính xác những gì bạn cần ở tốc độ phù hợp.