Benefits of the DTO Model

I have been engaged in Web application development since I started my work. Naturally, I use layer-3 MVC. When I first joined the company, I used layer-3 MVC. the version of XX applies the Struts + expresso method, and the intermediate things are naturally controlled by themselves. Information Transmission relies on the custom * vo JavaBean. Of course, it was a good architecture at the time;

We developed the new platform version around the beginning of. The project team adopted the Struts + spring + hibernate architecture, and the performance Layer still adopted the previous version, at most, the configuration file is broken down to solve the conflict of configuration file updates in multi-person development programs, from the original one to one for each module, then, configure the modules to the root configuration. Spring is a good thing. Although spring's transaction management is only a small part of spring, it brings great benefits. We all know that the C ++ program needs to handle garbage collection by itself, while Java uses the Garbage Collector, which saves us a lot of time without the programmer thinking about garbage collection. For example, our business layer needs a service class. We do not need to manually create objects at the root, but use the di function of spring
Object injection recently. As you can see, Java + spring is good. You don't need to create or destroy objects. The JVM + Spring framework is fully available to help us with programming. Spring AOP allows us to look at the problem from another perspective, which is of great help for implementing permission management.
In this version, information transmission is divided into two types:
* Vo JavaBean: used for presentation and Business Layer
* Po JavaBean: Used for the business layer and persistence layer

In fact, this is the question I want to raise. Although Vo/Po Division also has its advantages and disadvantages,
1. Clear transaction processing
2. Make the system more loosely coupled
3. Information not required for the performance layer is only used for Po, instead of VO, which is helpful for performance.
4. Vo/PO can be the same or different, which brings some flexibility to the program.

However, it also has disadvantages. In real enterprise-level development, there are usually many tables in the database, and the business is complicated, naturally, there is a lot of one-to-many relationships between tables. This relationship not only brings a lot of performance load to hibernate, but in this case, the VO cannot use the shortest copy, because there are still objects in the object, such a JavaBean should be a heavyweight Object if there are many associated objects. If the page needs to implement processing 10000 or more such objects, what will happen to you? (bandwidth is not enough, a large amount of memory is exhausted, the system runs down rapidly, or even out of momery !!! )

If we can use DTO to encapsulate complex cascading domain objects during system optimization and design, we can only include the data to be displayed and try not to include other objects,
Is the situation better.
In fact, I first saw this problem in Buffalo-Ajax. (By The Way, buffalo is a good thing. It will become pale and powerless if no web program is available in the future)
If you like Gmail as much as you do, let's get to know about it. (Let's try again. Buffalo is well encapsulated and can be used for half an hour to learn how to use it. Instead of looking at his source code, she is very attractive to use JavaScript to implement the burlap protocol, incredible)

Coolwangyu@Gmail.com