Đối với một dự án mới, JPA luôn là công cụ được khuyến nghị để xử lý dữ liệu quan hệ hay có những trường hợp mà Spring JdbcTemplate là lựa chọn tốt hơn? Một số yếu tố cần xem xét trong câu trả lời của bạn:
Câu trả lời:
Sử dụng Spring JdbcTemplate nếu bạn không muốn truy cập lược đồ 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 quyền truy cập cấp thấp hơn, linh hoạt hơn nhưng có lẽ cũng có nhiều bản soạn thảo hơn.
Spring JdbcTemplate có thể được sử dụng dễ dàng hơn với các lược đồ cơ sở dữ liệu kỳ lạ và tiêu điểm thủ tục đượ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 các nhà phát triển biết cơ sở dữ liệu quan hệ, SQL và các giao dịch. Tuy nhiên, với JPA, bạn sẽ nhận được nhiều phức tạp hơn.
Theo hiểu biết của tôi, JPA có thể dễ dàng cắm vào các lớp bộ nhớ đệm dữ liệu hơn, vì trọng tâm hướng đối tượng làm cho việc xác định, cập nhật và hủy bỏ mục nhập bộ nhớ cache dễ dàng hơn.
Bạn có thể tinh chỉnh các chương trình phụ trợ dựa trên JdbcTemplate tốt hơn, nhưng đối với hầu hết các trường hợp, có nhiều mã liên quan 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 có được một mô hình miền cho lược đồ cơ sở dữ liệu của mình, bạn thường sẽ cần sử dụng các lớp DTO bổ sung. Sử dụng JdbcTemplate, bạn có thể trực tiếp thao tác với các lớp DTO.
Tôi hơi muộn với bài đăng này, nhưng tôi có xu hướng sử dụng JdbcTemplate thay vì 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 mình. Tôi thấy hầu hết thời gian, các ứng dụng của tôi đang sử dụng các chế độ xem DB, nơi tôi đẩy hầu hết các logic nghiệp vụ lên. Tôi đã phân lớp đúng các DAO có triển khai JdbcTemplate. Nó cho cảm giác "sạch sẽ" và hầu hết mã soạn sẵn bị ẩn bởi JdbcTemplate (và tài liệu trực tuyến của nó có vẻ tốt hơn nhiều so với nội dung ORM). Thời gian giới hạn tôi đã sử dụng một cái gì đó như Hibernate, tôi thấy khi nó hoạt động, nó tiết kiệm cho tôi một chút thời gian ... nhưng khi nó không hoạt động bình thường, tôi phải mất nhiều ngày gỡ lỗi "WTF". Tôi chưa bao giờ phải dành hơn 20 phút để gỡ lỗi các lần hiển thị JdbcTemplate DAO. Tôi nghĩ rằng chìa khóa, như những người khác đã lưu ý, là bạn cảm thấy thoải mái như thế nào với SQL / Thiết kế lược đồ
Tôi đồng ý với @Timo. Thông tin chi tiết khác mà tôi sẽ thêm / mở rộng là ORM có ngữ nghĩa khác với truy cập sql thuần túy vào dữ liệu của bạn.
Mục đích của ORM là loại bỏ thực tế rằng dữ liệu của bạn nằm trong 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ã lâu dài; thực tế là bạn đang sử dụng ORM sẽ ẩn đối với mô hình của bạn.
Do đó, ORM rất giỏi trong việc làm cho 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 mình, trình bày, cập nhật, 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 vì khi bạn truy cập vào dữ liệu của mình, bạn 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 hóa' các cá thể đối tượng của mình khỏi dữ liệu, điều này có thể phức tạp và dễ xảy ra 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ụ đó 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 tình huống trong đó 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 đã đi quá lâu.
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à lệnh gọi sql 'chèn qua select' để tạo các hàng mới. Nó nhanh chóng, mã đơn giản hơn.
Một điều khác cần xem xét 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 nhóm 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 đối với một dự án có kỳ vọng cao. Có rất nhiều thứ để học và nó không hề nhỏ - thực sự là bạn đang giao dịch một bộ phức tạp này với một bộ phức tạp khác khi lựa chọn sử dụng jdbc vs orm.
Nó không được đề cập trong các câu trả lời khác nhưng bạn có thể sử dụng cả hai. Trong Ứng dụng của mình, 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 nơi 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.jdbcTemplate.queryForList("SELECT .. ",SomeProjectPojo.class);
}
}
Điều tuyệt vời về Spring là bản dịch ngoại lệ từ các ngoại lệ JPA sang phân cấp ngoại lệ Spring Dao hoạt động với cả JPA và jdbcTemplate. Vì vậy, hãy sử dụng JPA khi nó có ý nghĩa và jdbcTemplate khi nó có ý nghĩa.
getSomeReport()có this.jdbcTemplate. ...nên hơn this.entityManager. ...không?
Trong công việc, chúng tôi sử dụng Hibernate JDBCTemplate vì nó có tính linh hoạt hơn. Nó cũng có hiệu suất tốt hơn JPA vì bạn không phải "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, các 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 với tốc độ phù hợp.