Phát triển Java 2.0: Lưu trữ đám mây với SimpleDB của Amazon, Phần 2

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?
Nội dung trích xuất từ tài liệu:
Phát triển Java 2.0: Lưu trữ đám mây với SimpleDB của Amazon, Phần 2Phát triển Java 2.0: Lưu trữ đám mây với SimpleDB của Amazon, Phần 2Sự tồn tại lâu bền của đối tượng cũ đơn giản với SimpleJPAViệ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ề SimpleDBthì sao? Trong phần hai của bài giới thiệu về SimpleDB, Andrew Glover cho bạnthấ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ụngcác đối tượng Java™ cũ đơn giản (POJO) để mô hình hóa miền (theo JPA - APItồn tại lâu bền của Java), SimpleJPA tự động chuyển đổi các kiểu dữ liệu nguyênthủ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ỏimộ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áchsử dụng API của Amazon để mô hình hóa một ứng dụng chạy đua theo phong cáchCRUD. 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ốicù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 JavaPersistence. Đ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ếtbấ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 vicủ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ậnmộ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ớiSimpleJPA 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àmcho 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ắtNhiề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ácbean thực thể của EJB (EJB entity beans); trước đó, về cơ bản chúng ta đã triểnkhai 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ảngmô 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ụngEntityManager 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ệunhư SimpleDB nên cung cấp cho chúng ta một lựa chọn tương tự. Cuối cùng chẳngphả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 XMLnào.JPA sử dụng hai trong số các chú thích chính là @Entity và @Id, chỉ rõ một POJOlà 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 đíchchuyể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ạythi 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 để đạidiện cho các thực thể đó, tuy nhiên — tôi chỉ sử dụng API thô của Amazon để duytrì 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àmnhư thế như trong Liệt kê 1:Liệt kê 1. Một đối tượng Race đơn giảnpublic class Race {private String name;private String location;private double distance;private List 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ínhcuối cùng trong số đó là một Collec ...