2010-02-12 33 views
6

Có bao giờ chấp nhận được đối với một DTO để có các phương pháp thể hiện trả về các giá trị có nguồn gốc dựa trên dữ liệu của DTO không? Hoặc DTO có phải là các thùng chứa dữ liệu thuần túy không có phương thức bổ sung nào (không phải là getters/setters) không?Có thể một DTO có các phương thức ví dụ trả về các giá trị dẫn xuất không?

Người theo chủ nghĩa thuần khiết trong tôi nói rằng việc logic kinh doanh trở nên dễ dàng để leo vào các phương pháp như vậy. Tuy nhiên, nếu (ví dụ) một DTO được chia sẻ trên các lớp ứng dụng, thì có thể có một đối số cho việc có các phương thức như vậy trên DTO.

Quan điểm của bạn về điều này là gì? Có bao giờ các tình huống mà nó được chấp nhận hay không, hoặc loại điều này có thể tránh được không? Và tại sao/tại sao không?

+0

câu hỏi hay, tôi sắp hỏi! – andy

Trả lời

6

DTO không nên có hành vi, chúng chỉ là các vùng chứa để vận chuyển dữ liệu trên các ranh giới quy trình và chỉ bao gồm các bộ định cư/getters.

Cần tránh mọi chi phí nếu không nó sẽ được hiểu là việc áp dụng sai mẫu DTO.

+2

Hầu hết các sách thực hành tốt nhất mà tôi đã xem xét trong năm vừa qua đã khuyên chống lại DTO. – Woot4Moo

+0

Câu hỏi đặt ra là đặc trưng về mẫu DTO cho dù nó có được sử dụng hay không. Vấn đề với DTO là nó bị áp dụng sai trong nhiều tình huống, ví dụ: nơi không có quy trình ràng buộc! Đó là lý do nó xung quanh, tổng hợp dữ liệu từ một quá trình từ xa để tiết kiệm các chuyến đi vòng tốn kém. – David

+0

Tôi có nên sử dụng @override compareTo trong DTO hay không được khuyến nghị? Tốt hơn là sử dụng trình bao bọc cho mục đích đó? –

Các vấn đề liên quan