How to avoid implementation of a wrong domain concept - software-design

Question

We have the following concept in our application (composed of a UI and a REST backend):
Container is-a-parent-of lineItems
a lineItem cannot be created without having a valid Container and both of these entities are persisted in DB via spring data.
The UI lists the lineItems in two pages
list view: the lineItems of a single Container are displayed
search page: the lineItems of different Containers are displayed
We have a single source of data for both of these UI pages. The data comes from a common REST backend which returns a list of lineItems wrapped in a POJOview object (along with other information) - current state.
Change needed - On the search page, now, we need to show some information from the Container of a lineItem. So, now we need to make available the data of a Container associated with a lineItem on the search page. We are currently discussing two possible approaches for doing it:
Approach 1:
POJOview {
List<LineItem>
List<Container>
}
This approach avoids implementation of a wrong concept(described below) which gets implemented in approach 2.
List<LineItem> and List<Container> are sent separately, so, less data gets transferred to the UI. If 20 lineItems belonging to 1 Container are sent, then there is only one object of the Container as compared to 20 Objects of Container in approach 2.
The code is easier to understand and maintain
A disadvantage is that it requires some extra logic in the search page for the UI to map the lineItem to its Container in the other list
Approach 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.
}
This approach implements a wrong concept in the backend in the sense that lineItem now contains the Container which is opposite of the domain concept (Container is-a-parent-of lineItems) and hence it is not intuitive and makes the code difficult to understand and maintain.
Each lineItem now contains Container, so, if we have 20 lineItems on the page belonging to the same Container, then the Container data which is now a part of lineItem gets loaded 20 times (performance hit)
This has an advantage of a quick fix
The problem is that despite all these facts, my colleague still maintains that Approach 2 is the optimal way since it is a quick fix and he sees nothing wrong in it. Am I missing something here?

Answer 1

As per my opinion, one of the good ways to implement would be as below:
The REST service can return data in following format:
a) A list of LineItem objects where each LineItem object contains just the ID of its container (note: it is not a wrong approach because the child objects can very well contain the reference to its parent as long as the parent data is not repeated in every child).
b) A list of container objects. Obviously only those containers should be returned that are referenced by the line items.
The front end logic can go over the list of line items and look up the container details in the container list.
The data items a) and b) can be sent via separate calls or a single call. Ideally if the REST principles are to be followed strictly and making two calls is not impacting performance, then two separate calls should be made and thus as per the REST principles LineItem Resource is retrieved in one call and Container Resource in another call.
By using this approach, the container information is not repeated, only the container IDs are repeated in the line item objects which should be okay in most cases.
Thus this approach is essentially similar to Approach 1) that you have described except for the fact that lineitems can contain the ID of their parents (container).
As per what I understand, Approach 2 mentioned in the question repeats the full container information for each lineitem object which is definitely wrong. Ids can be repeated but not the full object whether the data is being retrieved from DB or being passed around in the backend or is being sent to front end.
Hope this provides some clarity.