JPA hợp nhất trong một ứng dụng web RESTful với DTO và Khóa lạc quan?

Question

Câu hỏi của tôi là: Có vai trò nào đối với JPA merge trong ứng dụng web không quốc tịch không?

Có rất nhiều cuộc thảo luận về SO về hoạt động merge trong JPA. Ngoài ra còn có một great article on the subject tương phản JPA hợp nhất thông qua quy trình Do-It-Yourself thủ công hơn (nơi bạn tìm thấy thực thể thông qua trình quản lý thực thể và thực hiện các thay đổi của bạn).

Ứng dụng của tôi có mô hình miền phong phú (thiết kế theo hướng tên miền) sử dụng chú thích @Version để sử dụng khóa lạc quan. Chúng tôi cũng đã tạo DTO để gửi qua dây như một phần của các dịch vụ web RESTful của chúng tôi. Việc tạo ra lớp DTO này cũng cho phép chúng tôi gửi cho khách hàng tất cả mọi thứ nó cần và không có gì nó không.

Cho đến nay, tôi hiểu đây là một kiến ​​trúc khá điển hình. Câu hỏi của tôi là về các phương thức dịch vụ cần cập nhật (tức là HTTP PUT) các đối tượng hiện có. Trong trường hợp này chúng ta có hai cách tiếp cận này 1) JPA Merge, và 2) DIY.

Điều tôi không hiểu là cách hợp nhất JPA thậm chí có thể được coi là một tùy chọn để xử lý cập nhật. Đây là suy nghĩ của tôi và tôi tự hỏi nếu có điều gì đó tôi không hiểu:

1) Để tạo đúng thực thể JPA tách biệt với DTO dây, số phiên bản phải được đặt chính xác ... khác với OptimisticLockException được ném. Nhưng spec JPA nói:

Một thực thể có thể truy cập vào trạng thái của trường phiên bản của nó hoặc tài sản hoặc xuất một phương pháp để sử dụng bởi các ứng dụng để truy cập vào phiên bản, nhưng không được sửa đổi giá trị phiên bản [30] . Chỉ nhà cung cấp kiên trì mới được phép đặt hoặc cập nhật giá trị của thuộc tính phiên bản trong đối tượng.

2) Hợp nhất không xử lý các mối quan hệ hai hướng ... các trường trỏ ngược luôn kết thúc bằng không.

3) Nếu bất kỳ trường hoặc dữ liệu nào bị thiếu từ DTO (do cập nhật một phần), thì việc hợp nhất JPA sẽ xóa các mối quan hệ đó hoặc loại bỏ các trường đó. Hibernate có thể xử lý các cập nhật từng phần, nhưng không thể hợp nhất JPA. DIY có thể xử lý các cập nhật một phần.

4) Điều đầu tiên mà phương pháp hợp nhất sẽ làm là truy vấn cơ sở dữ liệu cho ID tổ chức, vì vậy không có lợi ích hiệu suất nào trên DIY.

5) Trong bản cập nhật DYI, chúng tôi tải thực thể và thực hiện thay đổi theo DTO - không có cuộc gọi đến merge hoặc persist cho vấn đề đó vì bối cảnh JPA thực hiện mẫu đơn vị công việc hộp.

Tôi có trực tiếp không?

Edit:

6) Merge hành vi liên quan đến các mối quan hệ có thể lười nạp differ amongst providers.

Answer 1

Sử dụng Hợp nhất không yêu cầu bạn gửi và nhận đại diện hoàn chỉnh của pháp nhân hoặc duy trì trạng thái phía máy chủ. Đối với các hoạt động loại CRUD-y tầm thường, nó rất dễ dàng và thuận tiện. Tôi đã sử dụng nó rất nhiều trong các ứng dụng web không quốc tịch, nơi không có nguy cơ bảo mật có ý nghĩa để cho phép khách hàng nhìn thấy toàn bộ thực thể.

Tuy nhiên, nếu bạn đã giảm hoạt động để chỉ chuyển các thông tin liên quan ngay lập tức, thì bạn cũng cần viết thủ công các dịch vụ tương ứng.

Chỉ cần nhớ rằng khi thực hiện cập nhật 'DIY' của bạn, bạn vẫn cần phải chuyển số phiên bản xung quanh trên DTO và so sánh thủ công số phiên bản với phiên bản xuất phát từ cơ sở dữ liệu. Nếu không, bạn không nhận được Khóa lạc quan kéo dài 'thời gian suy nghĩ của người dùng' mà bạn sẽ có nếu bạn đang sử dụng cách tiếp cận đơn giản hơn với hợp nhất.

1. Bạn không thể thay đổi phiên bản trên một thực thể được tạo ra bởi các nhà cung cấp, nhưng khi bạn đã thực hiện dụ của riêng bạn của lớp thực thể với từ khóa new nó là tốt và dự kiến ​​sẽ thiết lập các phiên bản trên đó.

2. Nó sẽ làm cho đại diện liên tục khớp với biểu diễn trong bộ nhớ mà bạn cung cấp, điều này có thể bao gồm làm cho mọi thứ rỗng. Hãy nhớ khi một đối tượng được sáp nhập mà đối tượng được cho là bị loại bỏ và được thay thế bằng đối tượng được trả về bằng cách hợp nhất. Bạn không được phép hợp nhất một đối tượng và sau đó tiếp tục sử dụng nó. Trạng thái của nó không được xác định bởi spec.

3. True.

4. Rất có thể, miễn là giải pháp DIY của bạn cũng đang sử dụng ID tổ chức chứ không phải truy vấn tùy ý. (Có những lợi ích khác khi sử dụng phương pháp 'tìm' trên truy vấn.)

5. Đúng.

Answer 2

tôi sẽ thêm:

7) Merge dịch để chèn hoặc cập nhật tùy thuộc vào sự tồn tại của các kỷ lục về DB, vì thế nó không đối phó một cách chính xác với update-vs-xóa đồng thời lạc quan. Tức là, nếu một người dùng khác đồng thời xóa bản ghi và bạn cập nhật nó, nó phải (1) ném một ngoại lệ đồng thời ... nhưng nó không, nó chỉ chèn bản ghi mới.

(1) Ít nhất, trong hầu hết các trường hợp, theo ý kiến ​​của tôi, cần. Tôi có thể tưởng tượng một số trường hợp mà tôi sẽ muốn trường hợp sử dụng này để kích hoạt một chèn mới, nhưng chúng là xa bình thường. Ít nhất, tôi muốn các nhà phát triển để suy nghĩ hai lần về nó, không chỉ chấp nhận rằng "hợp nhất() == updateWithConcurrencyControl()", bởi vì nó không phải là.