Điểm của việc sử dụng DTO (Đối tượng truyền dữ liệu) là gì?

Điểm của việc sử dụng DTO là gì và nó có phải là một khái niệm lỗi thời không? Tôi sử dụng POJO trong lớp xem để truyền và duy trì dữ liệu. Những POJO này có thể được coi là một thay thế cho DTO không?

DTO là một mẫu và nó được triển khai (POJO / POCO) độc lập. DTO cho biết, vì mỗi cuộc gọi đến bất kỳ giao diện từ xa nào đều đắt tiền, phản hồi cho mỗi cuộc gọi sẽ mang lại càng nhiều dữ liệu càng tốt. Vì vậy, nếu nhiều yêu cầu được yêu cầu mang dữ liệu cho một nhiệm vụ cụ thể, dữ liệu sẽ được mang theo có thể được kết hợp trong DTO để chỉ một yêu cầu có thể mang lại tất cả dữ liệu cần thiết. Danh mục mô hình kiến ​​trúc ứng dụng doanh nghiệp có nhiều chi tiết hơn.

DTO là một khái niệm cơ bản, không lỗi thời.

DTO là một khái niệm (các đối tượng có mục đích thu thập dữ liệu được máy chủ trả về máy khách) chắc chắn không bị lỗi thời.

Có gì là hơi lạc hậu là khái niệm của việc có DTOs chứa không logic chút nào, được sử dụng chỉ để truyền dữ liệu và "ánh xạ" từ đối tượng miền trước khi truyền cho khách hàng, và có ánh xạ tới xem mô hình trước khi chuyển chúng đến lớp hiển thị. Trong các ứng dụng đơn giản, các đối tượng miền thường có thể được sử dụng lại trực tiếp dưới dạng DTO và được truyền trực tiếp đến lớp hiển thị, do đó chỉ có một mô hình dữ liệu thống nhất. Đối với các ứng dụng phức tạp hơn, bạn không muốn hiển thị toàn bộ mô hình miền cho máy khách, do đó, việc ánh xạ từ các mô hình miền sang DTO là cần thiết. Có một mô hình khung nhìn riêng biệt sao chép dữ liệu từ các DTO gần như không bao giờ có ý nghĩa.

Tuy nhiên, lý do tại sao khái niệm này đã lỗi thời thay vì sai lầm đơn giản là một số khung / công nghệ (chủ yếu cũ hơn) yêu cầu nó, vì các mô hình miền và chế độ xem của chúng không phải là POJOS và thay vào đó gắn trực tiếp với khung.

Đáng chú ý nhất là Đậu thực thể trong J2EE trước tiêu chuẩn EJB 3 không phải là POJO và thay vào đó là các đối tượng proxy được xây dựng bởi máy chủ ứng dụng - đơn giản là không thể gửi chúng đến máy khách, vì vậy bạn không có lựa chọn nào về việc tách lớp DTO riêng biệt - đó là bắt buộc.

Mặc dù DTO không phải là một mẫu lỗi thời, nó thường được áp dụng một cách không cần thiết, điều này có thể làm cho nó có vẻ lỗi thời.

Mẫu bị lạm dụng nhiều nhất trong cộng đồng Java Enterprise là DTO. DTO được xác định rõ ràng là một giải pháp cho một vấn đề phân phối. DTO có nghĩa là một thùng chứa dữ liệu thô, giúp vận chuyển dữ liệu giữa các quy trình (tầng) một cách hiệu quả. ~ Adam Biên

Ví dụ: giả sử bạn có một JSF ManagedBean. Một câu hỏi phổ biến là liệu bean có nên giữ tham chiếu trực tiếp đến Thực thể JPA hay nó nên duy trì tham chiếu đến một số đối tượng trung gian mà sau đó được chuyển đổi thành Thực thể. Tôi đã nghe thấy đối tượng trung gian này được gọi là DTO, nhưng nếu ManagedBeans và Thực thể của bạn đang hoạt động trong cùng một JVM, thì việc sử dụng mẫu DTO sẽ có rất ít lợi ích.

Xem xét các chú thích xác thực Bean. Các thực thể JPA của bạn có thể được chú thích với các xác nhận @NotNull và @Size. Nếu bạn đang sử dụng DTO, bạn sẽ muốn lặp lại các xác nhận này trong DTO của mình để khách hàng sử dụng giao diện từ xa của bạn không cần gửi tin nhắn để biết họ đã thất bại trong việc xác thực cơ bản. Hãy tưởng tượng tất cả công việc bổ sung sao chép chú thích Xác thực Bean giữa DTO và Thực thể của bạn, nhưng nếu Chế độ xem và Thực thể của bạn đang hoạt động trong cùng một JVM, thì không cần phải thực hiện công việc bổ sung này: chỉ cần sử dụng Thực thể.

Liên kết của IAmTheDude với Danh mục mô hình kiến ​​trúc ứng dụng doanh nghiệp cung cấp một lời giải thích ngắn gọn về các DTO và đây là nhiều tài liệu tham khảo mà tôi tìm thấy chiếu sáng:

• CÁCH XỬ LÝ VỚI J2EE VÀ THIẾT KẾ THỰC HIỆN
• Cách sử dụng DTO trong JSF + Spring + Hibernate
• Ưu và nhược điểm của đối tượng truyền dữ liệu

Tuyệt đối không! Gần đây tôi đã học được những bài học về việc sử dụng DTO tốt hơn là đối tượng kinh doanh mà bạn sử dụng (có thể bị ràng buộc với trình ánh xạ ORM của bạn).

Tuy nhiên, chỉ sử dụng chúng khi chúng phù hợp để sử dụng và không chỉ vì mục đích sử dụng vì chúng được đề cập trong một số cuốn sách mẫu hay.
Một ví dụ điển hình xuất hiện trong đầu tôi là khi bạn tiếp xúc với một số loại giao diện cho bên thứ 3. Trong trường hợp như vậy, bạn muốn giữ các đối tượng trao đổi khá ổn định mà bạn thường có thể đạt được độc đáo với DTOs.

Một nơi tôi thấy các DTO đặc biệt hữu ích là trong việc chứa logic cho các phản hồi API. Với mẫu này, thật dễ dàng để quản lý các loại phản hồi khác nhau từ các đối tượng đến các định dạng khác nhau theo cách có thể kiểm tra được. Sử dụng mẫu này với vai trò hiện tại của mình, chúng tôi đã có thể bắt đầu thử nghiệm các định dạng phản hồi cho các API của chúng tôi, điều này rất có giá trị vì ngăn xếp của chúng tôi trở nên đồng hình hơn với các máy khách khác nhau (http / mobile). Chắc chắn không lỗi thời.