DTO Dao Vo Bo Po Pojo-
Potian wrote: Identify some noun: 1. VO: It is actually vague, usually refers to ValueObject and ViewObject 2. ViewObject, the interface exhibits the required object, such as FORMBEAN 3 for Struts. Value Object, early as the general name of ValueObject and Transfer Object. In fact, the true meaning of Value Object is its content, not identity 4. Transfer Object: Data transfer objects, subjects between applications, in a distributed application, usually improves overall performance 5. PO: Maybe Persistent Object, basically Entity is in different architecture and implementations, which may be repeated, or may not overlap. If you want to make a framework for all systems, you need to strictly distinguish between each object. For example, JDO's PO cannot be used as TO, it should not be separated from PM, for example, you can choose to use ViewObject (such as struts's formbean) as TO, but it is not suitable in Tapestry and Webwork. But in many times, it is most important to be able to easily and use it. Robbin wrote: Pojo is an object that is an ordinary Java object, which is different from the object with heavy container control functions such as EJB, which is not the object of enhanced, such as JDO static enhance It is not similar to the dynamic Byte Code Generation similar to Hibernate. That is to say, the concept of POJO is relative to the other Class of the handfoot, it is not passive. Cao Xiao Gang actually, why do you want to do DAO? Nothing: 1. Managing Connection / Transaction 2, which is easy to perform statistics / log operation; 3, facilitate permission control; DAO mode, there are two types of objects, One is DAO, one is ValueObject. In this case we discussed, Value Object is Pojo corresponding to Hibernate. So, according to my understanding, Dao is a Transaction wrapper, its logical structure is a specific business of business. Here, the database's Transaction and business transactions are unified. Here is a good article about Dao. http://www-106.ibm.com/developerWorks/java/library/j-dao/
BO contains business logic
Stay this memo.
http://www.aspectoriented.org:9080/space/2004-04-22#dto?_ I need?
Potian wrote:
DTO? What do I need? I have two projects in hand, one is my own hotel reservation, and the other is to construct their remote frame with Weihello.
DTO's demand comes from two aspects, first:
Our objects may be changed by certain framework or product, with system resources of certain server, which are not doubtful after transmitting to the far end, so that these objects cannot be operated. JDO is a typical example, which enhances objects, with a PersistenceManager. Our object implements the Remote interface, so in RMI, all access to these objects will cause remote procedure calls. This is unacceptable in performance. Therefore, the DTO data transmission object is to transfer data in different process space. Like the first question, if our web apps and our business code are in the same process space, using the OpenPersistenceManagerInView mode should be resolved.
But DTO has also caused a lot of questions:
Object data, DTO is usually pure data, rarely supplied, just a bunch of data objects, DTO, very few containing the entire object structure, otherwise parsing and build in the service side will be very complex
That is, it is difficult for us to treat the DTO as a real object, and usually the service is like a number of functions, responsible for manipulating DTO, standard data and behavior separation.
Our View can only access the data of the tablet when you use DTO to change system information. Passing to Service, each service is forwarded to DTOFActory for translation, and vice versa every service takes DAO to translate into DTO tablet data through DTOFActory, this workload is very large. In addition to the case of the object contains other objects, we have no way to use the access methods provided directly to these object itself, but must operate with the method of addXXX (LONG containing object ID, XXXDTO DTO).
For distributed applications (such as Weihello's remote framework), this is an unhaneable thing. But for a program that does not need to be distributed (notice that it is not a cluster), this is not necessary. Rough estimation, at least 90% of Web applications do not need to be distributed, that is, the service code and view can be placed in the same JVM.
Therefore, I have no longer willing to achieve such a big pile of DTO for a program that never distribute, the result is that my code is reduced to about 50%, and all of my code can be very simple, OO is used. Thank Hibernate's Pojo lasting and powerful features of OGNL.
In case my program is too much load on the same server, the first step is to separate the database server and the application server, because the application server is a large number of CPUs, and the database server must be in the low tide of the CPU, and vice versa. This can greatly increase load capacity. I can cluster and load balancing, of course, don't need to be distributed.
If my application loads, there is no way to solve it. When each component must be separated on a different machine, I will consider DTO.
