如何避免实施错误的领域概念
How to avoid implementation of a wrong domain concept
我们的应用程序中有以下概念（由 UI 和 REST 后端组成）：
Container is-a-parent-of lineItems
a lineItem 不能在没有有效 Container 的情况下创建，并且这两个实体都通过 spring 数据持久保存在数据库中。
UI 分两页列出 lineItem
列表视图：显示单个Container的lineItem
搜索页面：显示不同Container的lineItem
对于这两个 UI 页面，我们都有单一数据源。数据来自一个通用的 REST 后端，其中 returns 包含在 POJOview object 中的 lineItem 列表（以及其他信息）- 当前状态。
需要更改 - 在搜索页面上，现在，我们需要显示 lineItem 的 Container 中的一些信息。因此，现在我们需要在搜索页面上提供与 lineItem 关联的 Container 的数据。我们目前正在讨论两种可能的方法：
方法一：
POJOview {
List<LineItem>
List<Container>
}
- 这种方法避免了在方法 2 中实现的错误概念（如下所述）的实现。
List<LineItem> 和 List<Container> 是分开发送的，因此传输到 UI 的数据较少。如果发送属于1个Container的20个lineItem，那么Container只有一个object，而[=10=的20个Objects ] 在方法 2 中。- 代码更易于理解和维护
- 缺点是 UI 的搜索页面需要一些额外的逻辑才能将
lineItem 映射到另一个列表 中的 Container
方法二：
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 lineItems) 因此它不直观并且使代码难以理解和维护。
- 每个
lineItem 现在包含 Container，因此，如果页面上有 20 个 lineItem 属于同一个 Container，那么 Container 现在属于 lineItem 的数据被加载 20 次（性能下降）
- 这有一个快速修复的优点
问题是，尽管存在所有这些事实，但我的同事仍然认为方法 2 是最佳方法，因为它是一种快速修复方法，而且他认为没有任何问题。我在这里遗漏了什么吗？
根据我的意见，一种好的实施方式如下：
REST 服务可以return 以下格式的数据：
a) LineItem object 的列表，其中每个 LineItem object 仅包含其容器的 ID（注意：这不是错误的方法，因为 child [=只要 parent 数据不在每个 child 中重复，32=]s 就可以很好地包含对其 parent 的引用。
b) 容器列表objects。显然，只有那些被行项目引用的容器才应该被 returned。
前端逻辑可以遍历行项目列表并在容器列表中查找容器详细信息。
数据项a)和b)可以通过单独调用或单个调用来发送。理想情况下，如果要严格遵循 REST 原则并且进行两次调用不会影响性能，则应进行两次单独的调用，因此根据 REST 原则，在一次调用中检索 LineItem 资源，在另一次调用中检索容器资源。
通过使用这种方法，容器信息不会重复，只有容器 ID 在行项目 object 中重复，这在大多数情况下应该没问题。
因此，此方法与您描述的方法 1) 基本相似，不同之处在于行项目可以包含其 parents（容器）的 ID。
据我了解，问题中提到的方法 2 为每个 lineitem object 重复了完整的容器信息，这肯定是错误的。 ID 可以重复但不能是完整的 object 无论数据是从数据库中检索还是在后端传递还是发送到前端。
希望这能提供一些清晰度。
我们的应用程序中有以下概念（由 UI 和 REST 后端组成）：
Container is-a-parent-of lineItems
a lineItem 不能在没有有效 Container 的情况下创建，并且这两个实体都通过 spring 数据持久保存在数据库中。
UI 分两页列出 lineItem
列表视图：显示单个
Container的lineItem搜索页面：显示不同
Container的lineItem
对于这两个 UI 页面，我们都有单一数据源。数据来自一个通用的 REST 后端，其中 returns 包含在 POJOview object 中的 lineItem 列表（以及其他信息）- 当前状态。
需要更改 - 在搜索页面上，现在，我们需要显示 lineItem 的 Container 中的一些信息。因此，现在我们需要在搜索页面上提供与 lineItem 关联的 Container 的数据。我们目前正在讨论两种可能的方法：
方法一：
POJOview {
List<LineItem>
List<Container>
}
- 这种方法避免了在方法 2 中实现的错误概念（如下所述）的实现。
List<LineItem>和List<Container>是分开发送的，因此传输到 UI 的数据较少。如果发送属于1个Container的20个lineItem，那么Container只有一个object，而[=10=的20个Objects ] 在方法 2 中。- 代码更易于理解和维护
- 缺点是 UI 的搜索页面需要一些额外的逻辑才能将
lineItem映射到另一个列表 中的
Container
方法二：
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(Containeris-a-parent-oflineItems) 因此它不直观并且使代码难以理解和维护。 - 每个
lineItem现在包含Container，因此，如果页面上有 20 个lineItem属于同一个Container，那么Container现在属于lineItem的数据被加载 20 次（性能下降） - 这有一个快速修复的优点
问题是，尽管存在所有这些事实，但我的同事仍然认为方法 2 是最佳方法，因为它是一种快速修复方法，而且他认为没有任何问题。我在这里遗漏了什么吗？
根据我的意见，一种好的实施方式如下：
REST 服务可以return 以下格式的数据：
a) LineItem object 的列表，其中每个 LineItem object 仅包含其容器的 ID（注意：这不是错误的方法，因为 child [=只要 parent 数据不在每个 child 中重复，32=]s 就可以很好地包含对其 parent 的引用。
b) 容器列表objects。显然，只有那些被行项目引用的容器才应该被 returned。
前端逻辑可以遍历行项目列表并在容器列表中查找容器详细信息。
数据项a)和b)可以通过单独调用或单个调用来发送。理想情况下，如果要严格遵循 REST 原则并且进行两次调用不会影响性能，则应进行两次单独的调用，因此根据 REST 原则，在一次调用中检索 LineItem 资源，在另一次调用中检索容器资源。
通过使用这种方法，容器信息不会重复，只有容器 ID 在行项目 object 中重复，这在大多数情况下应该没问题。
因此，此方法与您描述的方法 1) 基本相似，不同之处在于行项目可以包含其 parents（容器）的 ID。
据我了解，问题中提到的方法 2 为每个 lineitem object 重复了完整的容器信息，这肯定是错误的。 ID 可以重复但不能是完整的 object 无论数据是从数据库中检索还是在后端传递还是发送到前端。
希望这能提供一些清晰度。