Я использую шаблон DTO в своем приложении. Я не создал выделенных ассемблеров для сборки dto из своих доменных объектов, вместо этого передаю объект домена в DTO и разрешаю ему создавать и возвращать надлежащим образом сконструированный DTO.Объекты передачи данных - Исключения
Подходит ли этот подход?
Допустимо ли для DTO выдавать исключения?
Немного сложно прокомментировать это без каких-либо подробностей, и в любом случае это, вероятно, зависит от вашей ситуации и личных предпочтений.
Одна вещь, которая меня поражает, заключается в том, что это может вызвать некоторые из ваших внутренних действий для клиента. Предположим, например, что вы это сделаете, передав объект домена в качестве параметра конструктору в классе DTO, этот конструктор также будет виден клиенту, получающему DTO, а также класс сущности домена, так как он понадобится быть известным для DTO, чтобы он мог принять его как параметр (для него должен существовать ссылка, чтобы он был допустимым параметром).
Я не знаю, является ли это проблемой для вас (или, если это даже то, как вы реализовали свою логику), но это может быть стоит подумать о ..
Обновление:
Что касается бросания исключений и логики в целом в DTO - мое личное предпочтение заключалось бы в том, чтобы сохранить такую вещь на абсолютном минимуме. Опять же, это может быть немного субъективным, но я могу думать по крайней мере по двум причинам:
Основное разделение проблем: DTO должен быть простым передаточным объектом и не более того.
Избегайте зависимостей: По моему опыту, если вы добавите логику в такие места, вы в конечном итоге добавите ссылки, о которых вы пожалеете позже. Поскольку вы, вероятно, захотите использовать и относиться к классу DTO из нескольких разных проектов, вам не нужны ссылки из DTO на один из этих проектов, так как это неявно добавляет ссылки между этими проектами. Во избежание любой логики в DTO гарантируется, что она не зависит от чего-либо вне собственной сборки.