I will start with a small example:
Imagine an application with a couple of entities.
EntityA -1---n-> EntityB -1---n-> EntityC
Let's say we have a service method that returns a list of EnityC instances. In the UI we want to display EntityC but also add some additional information to the entity that is only relevant for the UI (maybe a css class or so). A common way to solve this would be to create a wrapper arround EntityC that can also carry the additional information.
public class EntityCWrapper implements EntityC, AdditionalInfo { ...}
or maybe use a transfer object as simple data structure:
public EntityTO {
public EntityC entity;
public AdditionalInfo info;
}
But what if the service returns a list of EnitityA instances and we need to attach AdditionalInfo to all entities in the instance graph (including the referenced entity instances of EntityB and EntityC)?
Does anyone have an idea or can point me to a design pattern suitable in this situation?
Assuming
AdditionalInfo
is instance specific (i.e. each instance ofEntityC
has a unique 121 relation to anAdditionalInfo
instance) best option would be to enhanceEntityC
definition to includeAdditionalInfo
inside it as member/..., which is optional and filled up by you.If you don't have control over
EntityC
then between teh two options you have given, I would say TransferObject seems better. You won't have to create new objects (ofEntityC
) that way.Have a look at the Role Object Pattern.
It descripes how an object can be extended with different stuff (called Roles). The pattern is more about how to add Bussiness Logic (that is why it is called roles) but may the idea helps you.
So your data model is essentially 1 to n using the following object as an example (contrived as it may be)
So I would treat this as my model, in terms of n-tier architecture and therefore this should map back to my database exactly. What comes up is you want your model to do something, whatever that may be. So you should create an object that is composed of Thing that can interact with business logic or outside services. Creating a transfer object would be correct in this case as it ensures your model remains valid and that the interfaces between both you and the outside service are not dependant on your model. It is sort of a Facade pattern and a Data Transfer Object.