Phát triển Java 2.0: Lưu trữ đám mây với
SimpleDB của Amazon, Phần 2
Sự tồn tại lâu bền của đối tượng cũ đơn giản với SimpleJPA
Việc mô hình hóa các đối tượng miền cho hầu như bất kỳ kiểu ứng dụng nào rất dễ
dàng khi sử dụng một khung công tác quan hệ như Grails, nhưng còn về SimpleDB
thì sao? Trong phần hai của bài giới thiệu về SimpleDB, Andrew Glover cho bạn
thấy cách sử dụng SimpleJPA, chứ không phải là SDK của Amazon, để duy trì các
đối tượng trong lưu trữ đám mây của SimpleDB. Ngoài việc cho phép bạn sử dụng
các đối tượng Java™ cũ đơn giản (POJO) để mô hình hóa miền (theo JPA - API
tồn tại lâu bền của Java), SimpleJPA tự động chuyển đổi các kiểu dữ liệu nguyên
thủy thành các chuỗi ký tự thân thiện với Amazon. Thực ra bạn không thể đòi hỏi
một cách tiếp cận đơn giản hơn nữa để lưu trữ trên đám mây.
Trong phần đầu của bài giới thiệu về SimpleDB này, tôi đã giới thiệu cho bạn cách
sử dụng API của Amazon để mô hình hóa một ứng dụng chạy đua theo phong cách
CRUD. Ngoài sự duy nhất hiển nhiên dành cho hầu hết các nhà phát triển Java về
cách tiếp cận chỉ theo chuỗi ký tự của Amazon với các kiểu dữ liệu, bạn có thể như
đã thấy chính mình đang xem xét API của Amazon với một chút hoài nghi. Cuối
cùng, các API để sử dụng một cơ sở dữ liệu quan hệ bây giờ là khá chuẩn và có
căn cứ — và có lẽ quan trọng hơn là chúng đã trở nên quen thuộc rồi.
Ở hậu trường, hiện nay nhiều framework quan hệ triển khai các API Java
Persistence. Điều này làm cho việc mô hình hóa các đối tượng miền cho hầu hết
bất kỳ kiểu ứng dụng Java nào trở nên vừa dễ dàng, vừa quen thuộc trên phạm vi
của các RDBMS. Khi bạn đã nắm vững về một mô hình hóa thì việc khó chấp nhận
một cách tiếp cận mới về mô hình hóa miền là điều hiển nhiên thôi — và tin tốt là
với SimpleDB, bạn không phải làm như vậy.
Trong phần 2 này, tôi sẽ hướng dẫn cho bạn cách cấu trúc lại ứng dụng chạy đua từ
Phần 1 cho phù hợp với đặc tả JPA. Sau đó, chúng ta sẽ gửi ứng dụng tới
SimpleJPA và tìm hiểu một số cách về nền tảng nguồn mở, đổi mới này có thể làm
cho thích nghi với việc mô hình hóa miền NoSQL và lưu trữ dựa trên đám mây, trở
nên dễ dàng hơn một chút.
Hibernate và JPA: Lịch sử tóm tắt
Nhiều nhà phát triển Java hiện nay sử dụng Hibernate (và Spring) để duy trì dữ
liệu. Ngoài việc là một tín hiệu về sự thành công của nguồn mở, Hibernate đã thay
đổi lĩnh vực ORM (Ánh xạ quan hệ-đối tượng) mãi mãi. Trước khi chúng ta có
Hibernate, các nhà phát triển Java đã phải đối phó với tình trạng sa lầy của các
bean thực thể của EJB (EJB entity beans); trước đó, về cơ bản chúng ta đã triển
khai các ORM riêng của mình hoặc đã mua một ORM từ một nhà cung cấp như
IBM®. Hibernate đã trút bỏ tất cả sự phức tạp đó và chi phí phải trả cho nền tảng
mô hình hóa dựa trên POJO mà nhiều người trong chúng ta coi là đúng hiện nay.
Người ta đã tạo ra Java Persistence API (JPA) để đáp ứng với tính phổ biến của sự
đổi mới của Hibernate về sử dụng các POJO để mô hình hóa dữ liệu. Hiện nay,
EJB 3.0 triển khai thực hiện JPA và do đó, thực hiện cả Google App Engine nữa.
Ngay cả bản thân Hibernate là một công cụ JPA, khi giả định bạn sử dụng
EntityManager của Hibernate.
Cứ cho là các nhà phát triển Java đã bắt đầu thoải mái với việc mô hình hóa các
ứng dụng lấy dữ liệu là trung tâm khi sử dụng các POJO, đúng là một kho dữ liệu
như SimpleDB nên cung cấp cho chúng ta một lựa chọn tương tự. Cuối cùng chẳng
phải nó giống như một cơ sở dữ liệu sao?
Mô hình hóa dữ liệu với các đối tượng
Để sử dụng SimpleJPA, chúng ta cần làm một chút trên các đối tượng Racer và
Runner của mình, đưa chúng lên ngang tầm với đặc tả JPA. May mắn thay, những
điều cơ bản của JPA khá đơn giản: bạn gắn các POJO bình thường với các chú
thích và việc thực hiện EntityManager sẽ lo nốt phần còn lại — không cần XML
nào.
JPA sử dụng hai trong số các chú thích chính là @Entity và @Id, chỉ rõ một POJO
là tồn tại lâu bền và mô tả khóa nhận dạng của nó, tương ứng. Đối với mục đích
chuyển đổi ứng dụng chạy đua của chúng ta sang JPA, chúng ta cũng sẽ cần sử
dụng hai chú thích để quản lý các mối quan hệ: @OneToMany và @ManyToOne.
Trong nửa đầu của bài này, tôi đã giới thiệu cho bạn cách duy trì những người chạy
thi và các cuộc thi chạy. Tôi chưa bao giờ sử dụng bất kỳ các đối tượng nào để đại
diện cho các thực thể đó, tuy nhiên — tôi chỉ sử dụng API thô của Amazon để duy
trì những đặc tính của cả hai thực thể. Nếu tôi muốn mô hình hóa một mối quan hệ
đơn giản giữa một cuộc chạy thi và những người chạy thi của nó, tôi đã có thể làm
như thế như trong Liệt kê 1:
Liệt kê 1. Một đối tượng Race đơn giản
public class Race {
private String name;
private String location;
private double distance;
private List<Runner> runners;
//setters and getters left out...
}
Trong Liệt kê 1, tôi đã chỉ rõ một đối tượng Race có bốn thuộc tính, thuộc tính
cuối cùng trong số đó là một Collection (bộ sưu tập) của các runner (người chạy