Hiển thị các mô hình miền qua API

8

Tôi đang xây dựng một API RESTful đơn giản cho một ứng dụng dựa trên web mà tôi đang làm việc và tôi đang tự hỏi về cách tốt nhất để làm lộ các mô hình miền của mình.

Giả sử tôi có một lớp Người dùng và tôi muốn cung cấp phản hồi JSON với các thuộc tính người dùng khác nhau. Tôi rõ ràng không muốn công khai mọi thuộc tính của mô hình của mình (những thứ như DateCreated, PasswordHash, v.v.) do vấn đề bảo mật và băng thông.

Tôi đã đọc vào Đối tượng truyền dữ liệu và tôi tự hỏi liệu đây có phải là hướng đi hay không. Nếu tôi đúng, tôi có thể chuyển, ví dụ, mô hình Người dùng cho Người dùng DTO của tôi và đảm bảo rằng DTO chỉ cho phép hiển thị các thuộc tính Người dùng tôi chọn (điều này cũng sẽ giúp tách các mô hình của tôi khỏi API công khai của tôi).

Là giải pháp này phù hợp hoặc có cách nào tốt hơn để đi về điều này?

Cảm ơn.

language-agnostic api domain-model

— James
nguồn

1

"Tôi đang xây dựng một API công khai đơn giản " và "Tôi rõ ràng không muốn công khai mọi tài sản" không có ý nghĩa đối với tôi, bạn có thể vui lòng làm rõ ý của bạn không?

— Uooo

Tôi đã chỉnh sửa câu hỏi của mình để cung cấp rõ ràng hơn, nhưng về cơ bản ý tôi là, đối tượng Người dùng của tôi có một số thuộc tính như Mật khẩu và DateCreated không được hiển thị trong biểu diễn JSON của Người dùng, nhưng hầu hết các dữ liệu người dùng khác nên có sẵn Tôi tự hỏi nếu DTO có thể giúp tôi tách các thuộc tính có sẵn khỏi các thuộc tính không có sẵn.

— James

6

Đó chính xác là một trong những lý do tại sao DTO tồn tại.

Sự cân bằng ở đây là việc thêm DTO làm cho việc triển khai của bạn phức tạp hơn một chút và do đó dễ bị lỗi - chẳng hạn như không khớp trong việc ánh xạ đối tượng miền thành DTO. Sử dụng các bài kiểm tra đơn vị cho việc này!

Một điều khác mà bạn có thể làm với DTO của mình và có xu hướng bị bỏ qua rất cao trong các dịch vụ RESTful là xử lý dữ liệu siêu văn bản cho các tham chiếu, các đối tượng lồng nhau và các hoạt động có thể.

Tham khảo PoEAA của Martin Fowler: "[...] điều đáng nói là một ưu điểm khác là đóng gói cơ chế tuần tự hóa để truyền dữ liệu qua dây. Bằng cách đóng gói tuần tự hóa như thế này, các DTO giữ logic này khỏi phần còn lại của mã và cũng cung cấp một điểm rõ ràng để thay đổi tuần tự hóa nếu bạn muốn. "

http://martinfowler.com/eaaCatalog/dataTransferObject.html

TL; DR: Tôi thích ý tưởng tách biệt mối quan tâm của logic miền và "hệ thống dây RESTful" thông qua DTOS, mặc dù giới thiệu một thiết kế phức tạp hơn.

— viniciushana
nguồn

1

Tôi đã nghĩ rất nhiều nhưng chỉ muốn làm rõ điều đó! Đối với tình hình của tôi ít nhất, tôi nghĩ rằng lợi ích lớn hơn những nhược điểm. Cảm ơn câu trả lời của bạn!

— James

giả sử mã kết thúc của bạn được gõ mạnh, độ phức tạp phát sinh được cân nhắc bởi kiểm tra loại thời gian biên dịch. Ánh xạ dto.setProp (entity.getProp) sẽ bắt đầu không biên dịch.

— Jason

3

Mặc dù đó không phải là mục đích chính của Đối tượng truyền dữ liệu , DTO có thể được sử dụng để đáp ứng mối quan tâm này theo cách tương tự với phần dữ liệu của Mô hình trình bày .

Như đã được chỉ ra, điều này có thể làm hỏng thiết kế của bạn và một cái gì đó đơn giản như một trường được thêm vào có thể yêu cầu thay đổi để bong bóng qua các lớp bổ sung. Do đó, bạn nên xem liệu bạn có thể cung cấp siêu dữ liệu để mô tả việc tuần tự hóa đối tượng hay không . Trong nhiều ngôn ngữ, điều này có dạng các chú thích chuyên biệt có thể được áp dụng cho các đối tượng miền của bạn để tránh việc dịch sang DTOs. Các gói như Jackson ( thông qua việc sử dụng Mixins ) thường đưa ý tưởng này ra xa hơn một chút để tách hoàn toàn siêu dữ liệu của bạn khỏi mô hình miền của bạn.

— smp7d
nguồn