2010-02-12 3 views
6

ли когда-нибудь приемлемо для DTO иметь методы экземпляра, которые возвращают значения, полученные на основе данных DTO в? Или должны ли DTO быть чистыми контейнерами данных без дополнительных методов (кроме геттеров/сеттеров)?Может ли DTO иметь методы экземпляра, возвращающие производные значения?

пуристов во мне говорит, что это далеко легко для бизнес-логики, ползать в таких методах. Однако, если (например) DTO разделяется между уровнями приложений, то, возможно, есть аргумент о наличии таких методов в DTO.

Каковы ваши взгляды на это? Существуют ли когда-либо ситуации, когда это приемлемо, или этого можно избежать? И почему/почему нет?

+0

хороший вопрос, я как раз собирался спросить! – andy

ответ

6

DTO не должны иметь поведения, они являются просто контейнерами для транспортировки данных через границы процессов и должны состоять только из сеттеров/геттеров.

Его следует избегать любой ценой, иначе это будет истолковано как неправильное применение шаблона DTO.

+2

Самые лучшие книги практики, которые я рассматривал как прошлый год, посоветовали против DTO. – Woot4Moo

+0

Вопрос был конкретно о шаблоне DTO, не следует ли его использовать или нет. Проблема с DTO заключается в неправильном применении во многих ситуациях, например. где нет границ процесса! Это причина, по которой она возникла, агрегирование данных из удаленного процесса для экономии дорогостоящих поездок. – David

+0

Должен ли я использовать @override compareTo в DTO или не рекомендуется? Лучше использовать обертку для этой цели? –