Design pattern to enhance an existing data structu

2019-07-04 16:08发布

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?

3条回答
smile是对你的礼貌
2楼-- · 2019-07-04 16:42

Assuming AdditionalInfo is instance specific (i.e. each instance of EntityC has a unique 121 relation to an AdditionalInfo instance) best option would be to enhance EntityC definition to include AdditionalInfo 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 (of EntityC) that way.

查看更多
Melony?
3楼-- · 2019-07-04 16:43

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.

查看更多
来,给爷笑一个
4楼-- · 2019-07-04 16:57

So your data model is essentially 1 to n using the following object as an example (contrived as it may be)

class Thing  
{  
   Collection<DooDad> dooDads;
}    

class DooDad  
{  
   Collection<DooDadDetail> details;  
}  

class DooDadDetail  
{  
   ... 
}  

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.

查看更多
登录 后发表回答