4

this is more a theoretical question than a practical one.

We have a layered architecture, sort of:

UI <--DTO1--> UI_JavaHandler <--DTO2--> Backend

DTO1 needs to have a bit more data than DTO2, and precisely an extra String. So the question is, should DTO1 extend DTO2 or should it encapsulate DTO2? In the first case, the code in UI_JavaHandler will be:

public void acceptAction(DTO1 dto1) {
    //do something with dto1.getString();
    backend.call(dto1);
}

Whereas in the second case:

public void acceptAction(DTO1 dto1) {
    //do something with dto1.getString();
    backend.call(dto1.getDto2());
}

Extending a Java DTO2 works fine, but I don't like the idea of using extension just for adding new data. I am used to using extension for adding new behaviour (like Animal being extended by Dog and Cat). Since the same effect can be used by aggregation we should not use extension, but I have no strong arguments against such (ab)use(?).

On the other hand, I may be completely wrong.

What is your take on this? Thank you.

BalusC
  • 1,082,665
  • 372
  • 3,610
  • 3,555
user1485864
  • 499
  • 6
  • 18
  • 3
    Really? Does DTO1 look just like DTO2? And is there a model object in the handler that looks just like both? Who told you that layer purity was an ideal worth preserving at all costs? My advice would be to stop creating all those DTOs. I'll bet you can't provide a single benefit for having them. – duffymo Jul 04 '12 at 14:40
  • Well you can use an adapter pattern to translate between DTO1 and DTO2, in case you have to. But yeah, I agree with @duffymo about not having so many DTOs without any specific benefits! – Sujay Jul 04 '12 at 14:42
  • Thank you for your comments. Just to be more precise. I used the term DTOs, but we are actually talking about Javabeans. Since they can be transmitted over networks, I preferred the term DTO over a Javabean [http://stackoverflow.com/questions/1612334/]. So... 'DTO1' simply contains some form data, and 'DTO2' is used to persist these data to the DB. So.. if cannot force the two layers (backend and UI) to accept the same data, what is the way to go forward? Thank again. – user1485864 Jul 05 '12 at 07:08
  • @duffymo, what is your point of view? Thanks. – user1485864 Jul 06 '12 at 05:46
  • I think I've made my point clear. Why can't the backend and UI accept the same data? Aren't they solving the same problem? – duffymo Jul 06 '12 at 13:32
  • @duffymo Well... Actually they are. I guess that I am paying the price that the inhouse MVC framework that I use forces me to pass all UI data to the Handler inside a single bean. Then the Backend, which I don't control, forces me to split the UI data when calling the method: 'backend.call(String s, DTO2)' because that way the DB structure is better matched. – user1485864 Jul 06 '12 at 14:12
  • So if all this is forced on you, why are you asking here? – duffymo Jul 06 '12 at 14:17

2 Answers2

0

If you are using Hibernate architecture, I would use @Transient annotation for those only needed for UI since DTO properties with the annotation will not be parsed to DB end.

e.g.

@Transient
private String type; //data used in UI only
Jake Kim
  • 112
  • 7
0

No inheritance for adding a dedicated field.

  • The backend data model is clearly separated and the extended class is used explicitly. This also prevents the anti-pattern having a DTO1Handler extends DTO2Handler and other inappropriate usages of the super class. A chained non-nullable getter is acceptible.

  • Extra data is a frequent phenomenon so as long as the methods must not be overriden to use that extra data, you are actually decoupling the data. You are saying this extra field is not part of calculations of those other fields.

  • Just for completeness sake: In rare cases such an extra field could be made a transient field of the super class.

Joop Eggen
  • 107,315
  • 7
  • 83
  • 138