How large should be Data Transfer Objects?

Question

As I understand, Data Transfer Objects are used for different purposes, so let's bound the scope with the view layer in Java (JSF) -based web-applications (i.e. there are usually some entity-objects mapped on a DB, which can be also used in a Business-Logic layer, and some transfer objects used in a presentation layer).

So, I have some misunderstanding about how should well-designed DTOs look. Should I keep them as small as possible? Or should I try to pass with them as much information as possible and design them in such way that only some (different in different use-cases) part of the DTO fields is initialized at a time?

Should I consider using some OO principles (at least inheritance and composition) when designing DTOs or they should be as simple as only a number of primitive-type fields with their accessors?

Answer 1

DTOs in any language should be pretty light weight. Whether or not to use inheritance is a question only you could answer - it really depends on the business needs. Otherwise the DTO itself should include the basic get/set properties.

Generally these objects are pretty light weight, however it really depends on the data / properties you need. If your DTO has 1 property vs 50 properties, if you need 50 so be it. When it comes time to passing data to functions / methods the DTO saves your life from having to add all those extra parameters. You're essentially just passing one object.

Answer 2

DTOs, if at all different from the domain objects/entities, should be as big as needed - you should transfer exactly all data that you need.

Answer 3

I prefer to keep my DTO as simple as possible. It is usually used between 2 layers. If I know I need to pass the DTO + more information to another layer, I'll create another DTO for it. The simple reason for me not using inheritence/composition is because it makes maintenance difficult... I wouldn't know what layer uses what fields, or whether the fields are initialized, etc. So, I adopt KISS concept here. :)

Answer 4

DTOs should be as lightweight as possible, distinct from the business objects, and limited in scope (for example package level objects).

I say they should be separate from the business objects, contrary to Bozho's statement "if at all different from the domain objects", because a DTO will often need setters that users of the business object should not use.

I have, for example, a Person object and a PersonDTO... the DTO needs a setter for the person's name (first, last, etc.) but that is retrieved from an external data source and my application is not allowed to change it, so my business object "Person" shouldn't have a setter.