Tuyên bố từ chối trách nhiệm:Tôi là người đứng đầu dự án Dữ liệu mùa xuân, vì vậy tôi sẽ chủ yếu trình bày về khía cạnh Dữ liệu mùa xuân của mọi thứ ở đây:
Tôi nghĩ rằng sự khác biệt cốt lõi giữa hai dự án nằm ở chỗ nhóm Hibernate OGM chọn tập trung nỗ lực của họ xung quanh JPA trong khi nhóm Dữ liệu mùa xuân thì không. Lý do như sau:
- JPA là một API quan hệ cố hữu. Hai câu đầu tiên của trạng thái đặc tả, rằng đó là một API để ánh xạ quan hệ đối tượng. Điều này cũng được thể hiện trong các chủ đề cốt lõi của API:nó nói về bảng, cột, liên kết, giao dịch. Các khái niệm không nhất thiết phải có thể chuyển giao trong thế giới NoSQL.
- Bạn thường chọn một cửa hàng NoSQL vì nó có những đặc điểm đặc biệt (ví dụ:truy vấn không gian địa lý trên MongoDB, có thể thực hiện duyệt đồ thị cho Neo4j). Không có cái nào trong số chúng (và sẽ có) trong JPA, do đó, bạn vẫn cần cung cấp các tiện ích mở rộng độc quyền.
- Tệ hơn nữa, JPA có các khái niệm chỉ đơn giản là hướng dẫn người dùng đi sai hướng nếu họ cho rằng họ làm việc trên cửa hàng NoSQL giống như đã được định nghĩa trong JPA:làm thế nào để thực hiện khôi phục giao dịch một cách hợp lý trên MongoDB?
Vì vậy, với Dữ liệu mùa xuân, chúng tôi đã chọn cung cấp một mô hình lập trình nhất quán đối với các cửa hàng được hỗ trợ nhưng không cố gắng ép buộc mọi thứ vào một API trừu tượng hóa quá mức duy nhất:bạn nhận được các triển khai mẫu nổi tiếng, bạn có được bản tóm tắt kho lưu trữ, hoạt động giống hệt nhau cho tất cả các cửa hàng nhưng hãy tận dụng các tính năng và khái niệm cụ thể của cửa hàng.