[Java]-concepts of pojo and Po

Source: http://user.qzone.qq.com/31584 (QQ space)

Http:// B .qzone.qq.com/cgi-bin/blognew/blog_output_data? Uin = 31584 & blogid = 1254066496 & styledm = Hangzhou & imtpd = qzs.qq.com & BDM = B .qzone.qq.com & mode = 2 & numperpage = 15 & blogseed = 0.29501750965040874 & property = Gore & timestamp = 1273108734 (actual address)

 

Pojo = pure old Java object or plain ordinary Java object or what ever.

Po = persisent Object Persistent Object

In other words, in some object/relation mapping tools, the persisent object that can maintain database table records is a pure Java object that complies with Java Bean specifications, without adding other attributes and methods. All of them are 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, we need to distinguish between a persistent object and a pojo. 

 

The persistent object must actually correspond to the entity in the database, so it is different from pojo. For example, pojo is created by new and recycled by GC. However, the persistent object is created in the insert database and deleted by the delete database. Basically, the lifecycle of persistent objects is closely related to databases. In addition, persistent objects can only exist in one database connection. After connnection is disabled, persistent objects do not exist, and pojo always exists as long as it is not recycled by GC. 

Because there are many differences, the Persistent Object Po (Persistent Object) isCodeIt must be different from pojo. At least the Po will add some attributes and methods to manage the entity status of the database relative to pojo. The goal of ORM is to use PO as much as possible to be consistent with pojo.ProgramPersonnel, they can use PO as pojo, but do not feel the existence of Po. 

The JDO implementation method is as follows: 
1. Compile pojo 
2. Compile pojo 
3. Use a dedicated JDO tool called enhancer. It is generally a command line program that runs manually or runs in the ant script to process the pojo class file, replace pojo with a po with the same name. 
4. The operation is actually a po, not a pojo. 

This method is a bit similar to JSP. jsp is also converted to servlet for running during compilation. It is actually running servlet rather than JSP at runtime. 

Hibernate has advanced implementation methods: 
1. Compile pojo 
2. Compile pojo 
3. run directly. during runtime, The cglib of hibernate dynamically converts pojo to Po. 

From this we can see that hibernate converts pojo bytecode to Po at runtime, while JDO converts pojo bytecode during compilation. It is generally considered that the JDO method is more efficient. After all, it is a compilation phase conversion. However, Gavin king, author of hibernate, said cglib is very efficient, and the runtime Po bytecode is generated very quickly, and the efficiency loss is almost negligible. 

In fact, the benefits of generating Po during the runtime are very large, so that programmers cannot access the Po, and the Po is completely transparent to them. Pojo can be used to manipulate Po more freely. In addition, the PO is generated during runtime, so incremental compilation and debugging are supported. JDO cannot do this. In fact, many people have complained about the issue of JDO enhancer during the compilation period. It is said that jbossdo will generate Po bytecode during the runtime instead of generating Po bytecode during the compilation period. 

Another problem is that the Po bytecode generated by enhancer of different JDO products may be different, which may affect the portability between JDO products, this is a bit similar to the portability problem of EJB. 

Bytes ----------------------------------------------------------------------------------- 
This problem leads to another JDO defect. 

Because of the Po status management method of JDO, when you get/set in the program, it is not actually obtained from the Po instance, but from JDO statemanager, so once the PM is disabled, the PO cannot be accessed. 

In JDO, you can also use some methods to make the Po available outside pm. For example, the PO is defined as transient, but after the Po is closed, there will be no po identity. Unable to perform status management across PM. 

While hibernate extracts values from the Po instance, so even if the session is closed, it can also get/set and perform cross-session state management. 

In multi-layer applications, since the persistence layer and service layer are separated from the web layer, the hibernate PO can be used as a pojo, that is, as a Vo, free Transfer between layers, regardless of whether the session is enabled or disabled. If you serialize this pojo, it can even be used in a distributed environment. (Not Suitable for lazy loading) 

However, the JDO Po cannot be reused after the PM is closed. Therefore, you must copy the Po and pass the VO to the business layer and web layer before the PM is closed. In a non-distributed environment, you can also use the threadlocal mode to ensure that the PM is always on, to avoid the need to copy the Po to VO each time. However, in any case, this is always an alternative, not as powerful as hibernate.