I have doubts about DTOs

[Deyan Perov]

Hi,
I need additional support and an explanation about DTOs.

1.  DTO is a POJO class and it is always copy-paste with attributes as an entity class has?
2. I saw some repositories where DTOs don't have all attributes. First how I understood DTO has to have only attributes which will be in response. But then I saw DTOs which are identical as entities. If the entity has 3 attributes then DTO will have all of them, if it has 15 it will have all of them too.
3.  I saw DTOs exactly as entities but then they have separated classes that have only attributes which are for request and then for a response. This way sounds good but it will have a lot of classes and can make a big mess.
4.  i.g. if a User has many addresses then it will be a List<AddressDTO> address, not List<AddressEntity> address ?
5. DTO always implements Serializable? I mean if an entity implements (it must be how I know)  then DTO has to do the same?
6. Every entity and DTO has to have its own generated serialVersionUID?
7. When we implement Serializable then we have to override equals() and hashcode()?

I am confused. I want to do and to learn in the right way but there are a lot (bad) applied to DTOs.

[Tim Holloway]

DTOs were defined as a pattern type for J2EE because Enterprise JavaBeans were not POJOs. They literally transferred data from the database-connected part of the app to the non-database parts of the app.

When J2EE became JEE, EJB Version 3 redefined EJBs as POJOs. So you can use the same data object everywhere without the intermediary DTO overhead.

So basically, DTOs are obsolete now.

[Deyan Perov]

Can you please elaborate a little more?
I read here and answer for use it yes and no.

Use it or not any way I wish someone to answer my question.

[Tim Holloway]

That topic dates to 2012. EJB3 has been around a while, but I'm not sure it was prevalent (or even available) back then, so DTO's would still have been needed before that.

The other example of "DTO" that was mentioned was as a serialized object for transmission between different environments (multiple JVMs or non-Java services). But I never considered that sort of representation as a "DTO". First, because it's not a Java object, it's an object converted to XML, JSON, JVM serial format or something other than Java. Secondly, because it's actually rarely good practice to simply shove objects verbatim between processes. Generally, it's more efficient and more secure to transmit only data specific to a given process request.