Is the Java – dto pattern deprecated?

Is the dto pattern still a valid option in a complete Java EE application cluster? Relevant applications use EJBs, hibernate, struts and spring Is there any problem transferring domain objects in this case?

Editor: just to clarify my question, is it the only reason to use domain objects with modern resources and improvements of Java EE? If not, does the dto pattern gradually disappear and should not be used in new applications?

Solution

Not deprecated if dto patterns should be used, depending on the application architecture For example, when you develop a web service (using jax-ws or jax-rs), you should send dto through the web so that c# or Python client applications may use it, and your web method should not return a hibernate like annotation. Remember, in other languages, entity will not be created using these annotations or other business logic

Editor (based on your comments): it depends on the software architecture For example, I am developing an SOA project. We use dto as the service layer and presentation layer What's more, we even use dto to handle database communication within the service. We only use SP to communicate with DB, so there is no hibernate or any other ORM tool to work there. We can use spring Dao, and the framework also uses dto You can now find many dto patterns in many applications

For more information, this will be a great question:

> Difference between DTO,VO,POJO,JavaBeans? (basically, any dto is a POJO). > Core J2EE Patterns – Transfer Object

Editor 2: another source of information that explains Martin Fowler's main reasons for using dto design

> LocalDTO

Conclusion: dto is not an anti - pattern Dto can only be used when you need to transfer data from one subsystem to another, and they have no default or standard communication mode