Стоит ли использовать геттеры и сеттеры в DTO? (C ++) - PullRequest
0 голосов
/ 18 ноября 2010

Мне нужно написать кучу DTO (объектов передачи данных) - их единственная цель - передавать данные между клиентским приложением (ями) и серверным приложением, чтобы у них было множество свойств, функция сериализации и функция десериализации .

Когда я видел DTO, у них часто бывают геттеры и сеттеры, но есть ли их смысл для этих типов классов? Я действительно задавался вопросом, ставлю ли я когда-нибудь проверку или выполняю вычисления в методах, но я думаю, что, вероятно, это не так, как кажется, выходит за рамки их цели.

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

Предполагая, что я все делаю правильно, что думают люди?

Спасибо!

РЕДАКТИРОВАТЬ: И если да, будут ли какие-либо проблемы с размещением реализации get / set в определении класса? Сохраняет повторение всего в файле cpp ...

Ответы [ 2 ]

4 голосов
/ 18 ноября 2010

Если у вас есть класс, чье явное назначение - хранить переменные-члены в одном месте, вы можете просто сделать их все открытыми.

0 голосов
/ 18 ноября 2010

Для объекта, скорее всего, не потребуется деструктор (вам нужен деструктор, только если вам нужно очистить ресурсы, например, указатели, но если вы сериализуете указатель, вы просто напрашиваетесь на неприятности).Вероятно, было бы неплохо иметь некоторые конструкторы синтаксических сахаров, но в действительности ничего не нужно.

Если данные представляют собой просто объект простых данных (POD) для переноса данных, то они являются кандидатом на то, чтобы быть структурой (полностью открытым классом).

Однако, в зависимости от вашего дизайна, вы можете рассмотреть возможность добавления некоторого поведения, например, метода .action (), который знает, как интегрировать данные, которые он переносит, в ваш реальный объект Model;в отличие от фактической модели, интегрирующей эти изменения сама.По сути, DTO можно рассматривать как часть контроллера (вход) вместо части модели (данные).

В любом случае, на любом языке, метод получения / установки является признаком плохой инкапсуляции.Это не ООП иметь геттер / сеттер для каждого поля экземпляра. Объекты должны быть богатыми, а не анемичными .Если вы действительно хотите Anemic Object, пропустите getter / setter и перейдите непосредственно к полной публичной структуре POD;использование getter / setter по сравнению с полностью открытой структурой практически не дает преимуществ, за исключением того, что это усложняет код, поэтому может дать вам более высокий рейтинг, если ваше рабочее место использует строки кода в качестве показателя производительности.

...