Сбалансированное разделение задач, скрытие реализации и объекты передачи данных

Сокрытие реализации требует, чтобы мы скрыли внутреннюю структуру класса от пользователя. Скажем для простоты: свести количество геттеров/сеттеров к минимуму.

Разделение интересов требует, чтобы для изменения класса была только одна причина. Таким образом, нельзя позволять классу сервисного уровня делать вещи сервисного уровня, например, и сохранять данные в хранилище данных.

Объекты передачи данных (DTO) используются для передачи данных с сервисного уровня на уровень доступа к данным.

Чтобы построить DTO, мне нужно, в худшем случае, прочитать все члены класса сервисного уровня. Для этого потребуется максимальное количество геттеров, что нарушает скрытие реализации.

Создание классов, которые должны быть преобразованы в DTO, из общего Storable абстрактного базового класса с виртуальным методом Dto buildDto() нарушит разделение задач.

Можете ли вы порекомендовать стратегии борьбы с этим? Или действительно существует общепринятая практика в этом отношении?


design-patterns data-transfer-objects separation-of-concerns data-hiding
person LCsa    schedule 18.01.2021    source источник

Ответы (1)


arrow_upward
0
arrow_downward

есть несколько вещей, которые не совсем верны в ваших определениях:

  • DTO — это сумки с недвижимостью. Классы без поведения, обычно используемые для обмена данными между различными Сервисами. Вы можете использовать их для определения полезной нагрузки для конечных точек REST в WebAPI или формы ваших ответов.
  • Сокрытие реализации не обязательно означает сокращение геттеров/сеттеров. Речь идет об абстрагировании внутренностей класса, данных и поведения.
  • Связь между сервисным уровнем и уровнем данных может осуществляться (и это действительно рекомендуется) с использованием моделей предметной области вместо простых классов POCO.

Последний пункт, вероятно, то, что вы ищете. Постарайтесь правильно определить свои модели предметной области: они не должны быть простыми пакетами свойств, иначе вы получите то, что обычно называют анемичными моделями.

Кроме того, если вы дадите нам более подробную информацию о своей общей архитектуре, мы сможем дать вам лучший совет :)

person David Guida    schedule 18.01.2021
comment
спасибо за подсказки и ключевые слова - я изучу концепции, которые вы назвали, и вернусь с правкой моего вопроса! - person LCsa; 23.01.2021