У меня есть проблема, которая беспокоит меня уже довольно давно, и я также придумал решение, вопрос здесь скорее в том, как ее наилучшим образом реализовать, поэтому я обращаюсь к вам за советом, если вы когда-либо сталкивались с такой ситуацией раньше (трудно найти что-либо полезное по этой теме в Интернете).

Ситуация

3-уровневая архитектура (богатый клиент, такой как Swing или Eclipse RCP или Android, веб-приложение с реализациями сервисного уровня, реляционная база данных). Мои модели — это POJOs (обычные старые объекты Java, чистые контейнеры данных с приемниками и установщиками), которые сохраняются (технический идентификатор на всех моих моделях).

Я часто имею дело с большими моделями, которые используются в совокупности, но их необходимо эффективно считывать и переносить. Допустим, у меня есть следующие модели:

• Пользователь, с именем входа, хэшем пароля, солью, именем / фамилией, адресом электронной почты, учетными данными для авторизации, изображением профиля
• Изображение с именем, типом содержимого и (обычно большими) данными
• Статья с текстом и автором (пользователем)

Проблема

Теперь, когда я размещаю список или загружаю статью, я не хочу загружать всего автора (пользователя), поскольку он предоставляет слишком много деталей (хэш пароля и соль) и содержит слишком много данных (учетные данные, изображение) для того, что мне действительно нужно в контексте статьи (имя / фамилия и электронная почта).

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

Решение

Для каждой модели я мог бы создать два варианта: подробный вариант с полным CRUD (создание, чтение, обновление, удаление) и упрощенный вариант, доступный только для чтения, который можно использовать как суррогат в агрегативных отношениях. Упрощенная версия модели также содержит технический идентификатор подробной версии, поэтому я мог бы получить его по запросу.

• Для пользователя: упрощенная модель содержит только имя / фамилию и адрес электронной почты.
• Что касается изображения: упрощенная модель поставляется без данных изображения.
• Автор статьи является упрощенной версией пользователя, а изображение профиля пользователя является упрощенной версией изображения.

Вопрос

• Это существующий шаблон?Это в некоторой степени связано с DTO (объектом передачи данных), но это не то же самое. Кто-нибудь видел это раньше?
• Использовали ли вы что-то подобное раньше? Есть какие-либо рекомендации по именованию, OO-взаимосвязи между двумя представлениями?

Я не могу соотнести ваш вариант решения с известным мне шаблоном. Но ваши требования могут быть выполнены путем последующего внедрения очень тонкого API (Web API) поверх вашего сервиса.

В нем есть две части,

• Чтение: как вы упомянули, вам может потребоваться направить определенный выбор элементов данных потребителю на основе использования / разрешений. Это можно учесть, указав набор фасетов во входящем запросе GET.

  Проверьте здесь пример,https://developer.linkedin.com/documents/people-search-api

• Запись: Для фрагментов используйте операции ИСПРАВЛЕНИЯ. Это даст вам гибкость при обновлении по полю.

  Посмотрите здесь пример:https://www.mnot.net/blog/2012/09/05/patch

В целом, это дает вам очень гибкий API с очень чистой моделью предметной области в вашем API. И в наши дни это широко принятый подход.

Надеюсь, это поможет.