Pojo = Pure Old Java Object or Plain ORDINARY JAVA Object or what Ever.
PO = persissant Object lastu
That is to say, in some Object / Relation Mapping tools, the Persisent Object that maintains the database table record is completely a pure Java object that conforms to the Java Bean specification, and does not add other properties and methods. All is like this:
PUBLIC CLASS User {
Private long id;
PRIVATE STRING NAME;
Public void setid (long id) {
THIS.ID = ID;
}
Public void setname (String name) {
THIS.NAME = Name;
}
Public long getId () {
Return ID;
}
Public string getname () {
Return Name;
}
}
First, you must distinguish your lasting objects and POJO.
The lasting object actually must correspond to the entity in the database, so and POJO is different. For example, POJO is created by NEW, reclaimed by GC. But lasting objects are created in the INSERT database, deleted by Database delete. Basically lasting object life cycles and databases are closely related. In addition, lasting objects can only exist in a database connection. After Connnection is turned off, the lasting object does not exist, and the POJO will always exist as long as it is not recycled by GC.
Since there are many differences, persistent object PO (Persistent Object) is definitely different on the code, and the at least PO will add some properties and methods to manage the database Entity status. The goal of ORM is to do as much as POJO is in use. For programmers, they can use PO as Pojo, but do not feel PO's presence.
The implementation method of JDO is this:
1, write POJO
2, compile POJO
3, using JDO's special tool called Enhancer, usually a command line program, manually run, or run in the Ant script, processes the Pojo's class file, replace POJO to the same name.
4. It is actually PO in the running period, not Pojo.
This method is a bit similar to JSP, and JSP is also running in the compile period to run, and the running period actually runs a servlet instead of JSP.
Hibernate's implementation method is more advanced:
1, write POJO
2, compile POJO
3, running directly, during the runtime, convert the POJO to PO dynamics by Hibernate's CGLIB.
It can be seen that hibernate is converted to PO at the runtime period to PO, while JDO is translated in compile. Generally speaking, JDO's way is slightly higher, after all, is a compile time conversion. However, Hibernate's author Gavin King said that the efficiency of CGLIB is very high, and the byte code generation speed of the running period is very fast, and the efficiency loss can almost ignore.
In fact, the benefits of running the PO are very large, so that for programmers, it is unable to come into contact with PO, and PO is completely transparent to them. Can be more free to manipulate the PO in pojo concept. In addition, since the runtime generation PO is generated, the incremental compile, incremental debugging can be supported. JDO can't do this. In fact, many people have complained that JDO's compilation ENHANCER problem is said, and it is said that JBossdo will use the running period to generate a PO bytecode without using the compile period to generate a PO byte code.
Another related problem is that the PO bytecode generated by the ENHANCER of the different JDO products may vary, which may affect the portability between JDO products, which is a bit similar to EJB portability. Another JDO defect is introduced by this problem.
Due to the JDO PO status management mode, when you get / set in the program, it is actually taken from the PO's instance, but is taken from the JDO State Manager?, Once the PM is turned off, PO can't Access it.
In JDO, you can also make PO can be used outside in PM, such as definition PO is TRANSIENT, but the PO is not Po Identity after PM is shut down. Unable to perform state management across PM.
Hibernate is taken from the PO instance, so even if sessions are closed, it can be Get / SET, which can be managed across session.
In a multi-layer application, since the persistence layer and the business layer and the web layer are separated, at this time, the Hibernate's PO can be used as a POJO, that is, as a Vo, free delivery between the layers, not Depending on the session is the opening or off. If you sequence this POJO, you can even be used in a distributed environment. (Not suitable for lazy loading)
However, the JDO PO cannot be used after the PM is closed, so it must be copied a VO before the PM is closed, and the VO is passed to the business layer and the web layer. In a non-distributed environment, you can also use the ThreadLocal mode to ensure that the PM is always open to avoid the copy operation of PO to VO each time. But in any case, this is always the power of the right, is not as strong as Hibernate.
