Tôi muốn phát triển dự án của mình trên Google App Engine với Struts2. Đối với cơ sở dữ liệu, tôi có hai tùy chọn JPA và JDO. Các bạn sẽ gợi ý cho tôi được không? Cả hai đều mới đối với tôi và tôi cần phải học chúng. Vì vậy, tôi sẽ tập trung vào một sau khi bạn trả lời.
Cảm ơn.
Câu trả lời:
JPA là tiêu chuẩn của Sun cho sự bền bỉ, JDO là IMHO đang chết (thực ra, nó đã chết nhưng vẫn chuyển động). Nói cách khác, JPA dường như là khoản đầu tư tốt hơn về dài hạn. Vì vậy, tôi đoán tôi sẽ chọn JPA nếu cả hai đều mới đối với tôi.
Nhóm Google GAE / J có một số bài đăng về điều này. Tôi sẽ tìm kiếm trên đó và xem xét ý kiến của mọi người. Bạn sẽ nhận được một thông điệp rất khác với những ý kiến được trình bày ở trên. Cũng tập trung vào thực tế rằng BigTable không phải là một RDBMS. Sử dụng các công cụ thích hợp cho công việc
Chỉ cần xem so sánh giữa JPA và JDO bởi chính DataNucleus: - http://www.datanucleus.org/products/accessplatform_2_1/jdo_jpa_faq.html Một điều mở mang tầm mắt.
Tôi là một người dùng vui vẻ của JDO. Tiếp tục phát huy nhé.
Những người tuyên bố JDO đã chết không phải là không có công. Đây là những gì tôi đọc được trong cuốn sách Pro EJB 3 Java Persistence API: "Ngay sau đó Sun thông báo rằng JDO sẽ được giảm xuống chế độ bảo trì đặc điểm kỹ thuật và Java Persistence API sẽ lấy từ cả JDO và các nhà cung cấp bền bỉ khác và trở thành một ứng dụng duy nhất được hỗ trợ chuẩn về phía trước. ”. Tác giả Mike Keith là trưởng nhóm đồng đặc tả trên EJB3. Tất nhiên anh ấy là một người ủng hộ lớn của JPA, nhưng tôi nghi ngờ anh ấy đủ thành kiến để nói dối.
Đúng là khi cuốn sách được xuất bản, hầu hết các nhà cung cấp lớn đều hợp nhất với JPA chứ không phải JDO, mặc dù JDO có nhiều tính năng kỹ thuật tiên tiến hơn JPA. Không có gì đáng ngạc nhiên vì những ông lớn trong thế giới EE như IBM / Oracle cũng là những nhà cung cấp RDBMS lớn. Nhiều khách hàng đang sử dụng RDMBS hơn không phải RDMBS trong các dự án của họ. JDO đã chết cho đến khi GAE tạo ra một cú hích lớn. Nó có ý nghĩa vì kho dữ liệu GAE không phải là cơ sở dữ liệu quan hệ. Một số tính năng của JPA không hoạt động với bigtable chẳng hạn như truy vấn tổng hợp, truy vấn tham gia, mối quan hệ nhiều-nhiều sở hữu. BTW, GAE hỗ trợ JDO 2.3 trong khi chỉ hỗ trợ JPA 1.0. Tôi sẽ giới thiệu JDO nếu GAE là nền tảng đám mây mục tiêu của bạn.
Đối với hồ sơ, đó là Google App Engine (GAE), vì vậy chúng tôi chơi với các quy tắc của Google chứ không phải với các quy tắc của Oracle / Sun.
Theo đó, JPA không phù hợp với GAE, nó không ổn định và nó không hoạt động như mong đợi. Cả Google đều không sẵn sàng hỗ trợ nó nhưng mức tối thiểu.
Và về phần khác, JDO khá ổn định trong GAE và nó (trong một số trường hợp mở rộng) đã được Google ghi nhận.
Tuy nhiên, Google không khuyến nghị bất kỳ cách nào trong số đó.
http://code.google.com/appengine/docs/java/datastore/overview.html
API cấp thấp sẽ cho hiệu suất tốt nhất và GAE là tất cả về hiệu suất.
Ví dụ: thêm 10 thực thể
Python: 68ms
JDO: 378ms
Java Native: 30ms
Trong cuộc đua giữa JDO và JPA, tôi chỉ có thể đồng ý với các áp phích về hạt nhân dữ liệu.
Trước hết, và cũng là quan trọng nhất, các áp phích của hạt nhân dữ liệu biết họ đang làm gì. Sau cùng, họ đang phát triển một thư viện bền vững và quen thuộc với các mô hình dữ liệu khác với mô hình quan hệ, ví dụ: Big Table. Tôi chắc chắn rằng id một nhà phát triển cho chế độ ngủ đông đã ở đây, anh ấy sẽ nói: "tất cả các giả định của chúng tôi khi xây dựng các thư viện cốt lõi của chúng tôi được kết hợp chặt chẽ với mô hình quan hệ, ngủ đông không được tối ưu hóa cho GAE".
Thứ hai, chắc chắn JPA được sử dụng rộng rãi hơn, là một phần của ngăn xếp Java EE chính thức sẽ giúp ích một chút, nhưng điều đó không nhất thiết có nghĩa là nó tốt hơn. Trên thực tế, JDO, nếu bạn đọc về nó, tương ứng với mức độ trừu tượng cao hơn JPA. JPA được kết hợp chặt chẽ với mô hình dữ liệu RDBMS.
Từ quan điểm lập trình, sử dụng các API JDO là một lựa chọn tốt hơn nhiều, bởi vì bạn đang thỏa hiệp về mặt khái niệm ít hơn rất nhiều. Về mặt lý thuyết, bạn có thể chuyển sang bất kỳ mô hình dữ liệu nào mà bạn mong muốn, miễn là nhà cung cấp bạn sử dụng hỗ trợ cơ sở dữ liệu bên dưới. (Trong thực tế, bạn hiếm khi đạt được mức độ minh bạch cao như vậy, bởi vì bạn sẽ thấy mình đặt các khóa chính của mình trên đối tượng của GAE và bạn sẽ tự ràng buộc mình với một nhà cung cấp cơ sở dữ liệu cụ thể, ví dụ như google). nó vẫn sẽ dễ dàng hơn để di chuyển.
Thứ ba, bạn có thể sử dụng Hibernate, Eclipse Link và thậm chí cả mùa xuân với GAE. Google dường như đã rất nỗ lực để cho phép bạn sử dụng các khuôn khổ mà bạn quen dùng để xây dựng các ứng dụng của mình. Nhưng những gì mọi người nhận ra khi họ xây dựng các ứng dụng GAE của mình như thể chúng đang chạy trên RDBMS là chúng rất chậm. Mùa xuân trên GAE là CHẬM. Bạn có thể google Google IO video về chủ đề này để thấy điều đó là đúng.
Ngoài ra, về nguyên tắc, tôi hoan nghênh việc tuân thủ các tiêu chuẩn là một điều hợp lý nên làm. Mặt khác, JPA là một phần của ngăn xếp Java EE khiến mọi người, đôi khi, mất khái niệm về các tùy chọn. Nếu bạn muốn, hãy nhận ra rằng Mặt máy chủ Java cũng là một phần của ngăn xếp Java EE. Và nó là một giải pháp gọn gàng không thể tin được để phát triển GUI web. Nhưng cuối cùng, tại sao mọi người, những người thông minh hơn nếu tôi có thể nói vậy, lại đi chệch khỏi tiêu chuẩn này và sử dụng GWT thay thế?
Trong tất cả những điều này, tôi phải khẳng định rằng có một điều rất quan trọng đối với JPA. Đó là Guice và sự hỗ trợ tiện lợi của nó cho JPA. Có vẻ như google đã không thông minh như bình thường ở điểm này và nội dung, hiện tại không hỗ trợ JDO. Tôi vẫn nghĩ rằng họ có đủ khả năng chi trả, và cuối cùng Guice cũng sẽ nhấn chìm JDO, ... hoặc có thể không.
Điều tôi nghĩ là tồi tệ khi sử dụng JDOtại thời điểm viết bài này là nhà cung cấp triển khai duy nhất Datanucleusvà hạn chế của việc đó là thiếu cạnh tranh dẫn đến nhiều vấn đề như:
extensionsStackOverflowTôi luôn hy vọng một ai đó để bắt đầu thực hiện các JDOđặc điểm kỹ thuật bản thân, có thể là sau đó họ sẽ đưa ra một cái gì đó nhiều hơn và hy vọng hơn miễn phí chú ý cho cộng đồng và không phải lúc nào làm phiền về việc bị trả tiền cho hỗ trợ, không nói rằng Datanucleustác giả chỉ quan tâm đến hỗ trợ thương mại , nhưng tôi chỉ nói.
Cá nhân tôi coi Datanucleuscác tác giả không có nghĩa vụ gì đối với Datanucleusbản thân cũng như cộng đồng. Họ có thể bỏ toàn bộ dự án bất cứ lúc nào và không ai có thể đánh giá họ về điều đó, đó là công sức và tài sản của chính họ. Nhưng bạn nên biết bạn đang làm gì. Bạn thấy đấy, khi một nhà phát triển trong chúng ta tìm kiếm một khuôn khổ để sử dụng, bạn không thể trừng phạt hoặc ra lệnh cho tác giả của khuôn khổ đó, nhưng mặt khác, bạn cần hoàn thành công việc của mình! Nếu bạn có thời gian để viết framework đó, tại sao bạn lại tìm kiếm một cái ngay từ đầu ?!
Mặt khác, JDObản thân nó có một số phức tạp như vòng đời đối tượng và những thứ không trực quan và phổ biến (tôi nghĩ vậy).
Chỉnh sửa: Bây giờ tôi biết cũng JPAthực thi cơ chế vòng đời đối tượng, vì vậy có vẻ như không thể tránh khỏi việc đối phó với các trạng thái vòng đời của thực thể tồn tại nếu bạn muốn sử dụng API ORM tiêu chuẩn (tức là JPAhoặc JDO)
Điều tôi thích nhất JDOlà khả năng làm việc với BẤT KỲ hệ quản trị cơ sở dữ liệu nào mà không cần nỗ lực đáng kể.
GAE / J dự kiến sẽ thêm MYSQL trước khi kết thúc năm.
JPA là con đường để đi vì nó dường như được thúc đẩy như một API được tiêu chuẩn hóa và gần đây đã có động lực trong EJB3.0 .. JDO dường như đã mất đi hơi thở.
Cũng không!
Sử dụng Objectify, vì nó rẻ hơn (sử dụng ít tài nguyên hơn) và nhanh hơn. FYI: http://paulonjava.blogspot.mx/2010/12/tuning-google-appengine.html
Objectectify là một API truy cập dữ liệu Java được thiết kế đặc biệt cho kho dữ liệu Google App Engine. Nó chiếm một "trung gian"; dễ sử dụng và minh bạch hơn JDO hoặc JPA, nhưng thuận tiện hơn đáng kể so với API cấp thấp. Objectectify được thiết kế để làm cho người mới sử dụng có năng suất ngay lập tức nhưng cũng thể hiện toàn bộ sức mạnh của kho dữ liệu GAE.
Objectectify cho phép bạn duy trì, truy xuất, xóa và truy vấn các đối tượng đã nhập của riêng bạn.
@Entity
class Car {
@Id String vin; // Can be Long, long, or String
String color;
}
ofy().save().entity(new Car("123123", "red")).now();
Car c = ofy().load().type(Car.class).id("123123").now();
ofy().delete().entity(c);