Как избежать реализации неправильной концепции домена

Question

В нашем приложении есть следующая концепция (состоящая из пользовательского интерфейса и бэкэнда REST):

Container is-a-parent-of lineItem s

a lineItem не может быть создано без действительного Container, и оба этих объекта сохраняются в БД через данные пружины.

Пользовательский интерфейс отображает lineItem s на двух страницах

• просмотр списка: отображаются lineItem одного Container

• страницы поиска: отображаются lineItem различных Container

У нас есть один источник данных для обеих этих страниц пользовательского интерфейса.Данные поступают из общего бэкэнда REST, который возвращает список lineItem, заключенных в объект POJOview (вместе с другой информацией) - текущее состояние.

Требуется изменение - теперь на странице поиска нам нужно показать некоторую информацию из Container из lineItem.Итак, теперь нам нужно сделать доступными данные Container, связанные с lineItem на странице поиска.В настоящее время мы обсуждаем два возможных подхода для этого:

Подход 1: POJOview { List<LineItem> List<Container> }

• Этот подход позволяет избежать реализации неправильной концепции (описанной ниже), которая реализуется в подходе 2.
• List<LineItem> и List<Container> отправляются отдельно, поэтому в пользовательский интерфейс передается меньше данных.Если отправлено 20 lineItem s, принадлежащих 1 Container, то существует только один объект Container по сравнению с 20 объектами Container в подходе 2.
• Код легчепонимать и поддерживать
• Недостатком является то, что для пользовательского интерфейса требуется дополнительная логика на странице поиска для сопоставления lineItem с Container в другом списке

Подход2: POJOview { List<LineItem> //insert Container of a lineItem as a member variable in the lineItem itself. Container instance is annotated with @Transient to avoid persistence in DB. }

• Этот подход реализует неверную концепцию в бэкэнде в том смысле, что lineItem теперь содержит Container, который противоположен концепции домена (Container is-a-parent-of lineItem s) и, следовательно, он не интуитивен и делает код трудным для понимания и сопровождения.
• Каждый lineItem теперь содержит Container, поэтому, если у нас есть 20 lineItemЕсли на странице, принадлежащей к тому же Container, то данные Container, которые теперь являются частью lineItem, загружаются 20 раз (снижение производительности)
• Преимущество быстрого исправления

Проблема в том, что, несмотря на все эти факты, мой коллега все ещесчитает, что подход 2 является оптимальным, так как это быстрое решение, и он не видит в этом ничего плохого.Я что-то здесь упускаю?

Answer 1

По моему мнению, один из хороших способов реализации был бы следующим:

Служба REST может возвращать данные в следующем формате:

a) Список объектов LineItem, гдекаждый объект LineItem содержит только идентификатор своего контейнера (примечание: это не неправильный подход, поскольку дочерние объекты могут очень хорошо содержать ссылку на своего родителя, если родительские данные не повторяются в каждом дочернем объекте).

б) Список объектов-контейнеров.Очевидно, что должны быть возвращены только те контейнеры, на которые ссылаются позиции.

Внешняя логика может просматривать список позиций и просматривать сведения о контейнере в списке контейнеров.

Элементы данных a) и b) могут отправляться через отдельные вызовы илиодин звонок.В идеале, если строго следовать принципам REST, а выполнение двух вызовов не влияет на производительность, следует выполнить два отдельных вызова, и, таким образом, согласно принципам REST ресурс LineItem извлекается в одном вызове, а ресурс контейнера - в другом вызове.

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

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

Согласно тому, что я понимаю, упомянутый в вопросе подход 2 повторяет полную информацию о контейнере для каждого объекта lineitem, который являетсяопределенно неправильно.Идентификаторы могут повторяться, но не полный объект, независимо от того, извлекаются ли данные из БД или передаются во внутреннем интерфейсе или отправляются во внешний интерфейс.

Надеюсь, это обеспечит некоторую ясность.