Common difficulties faced by the ORM transparent Persistence Solution

Source and comments: http://www.blogjava.net/calvin/archive/2006/01/05/26791.html

Author: Jiangnan Baiyi
 
Excerpt from the last FB blow:

Data Access Technologies except JDBC include EJB, hibernate, JDO, and ibatis. However, any Orm must face the same dilemma. If it is transparent and persistent, more worried-the Java data access technology is still slowly bridging the gap ,. netCommunityDo not need eye heat heartbeat:

1. Query Language-SQL statements that were originally designed to get rid of, but not as mature as SQL statements.
Because of queryobject and criteria API, the readability is too poor, and all the technical solutions finally go back to the SQL they originally wanted to get rid. In addition, because it is a hasty design, it is not as mature as SQL, there are always many places that cannot be done. For example, in the first EJB Ql, almost nothing can be done, while in hibernate 3.0 hqlCodeIf we abandon implementation, we can achieve a relatively satisfactory level.

2. Active loading and lazy loading-cannot be customized on demand as per SQL
The difference between orm and JDBC access is to include the objects associated with the object, rather than the SQL custom resultset, as the subject of data loading.

When an active loading policy loads an order object, it then loads the customer object and product object. If the product object contains a category object, the entire database is dragged half. Even if you don't play with the continuous viewing, It is a headache to load the clob objects randomly.

This corresponds to a lazy loading policy, such as the initial version of EJB. It is reported that each attribute queries the database once, and the number of database round-trips is too scary.

The ORM solution allows users to define these two policies to achieve a balance. By default, lazy load is defined on One-to-multiple associations, and active loading layers are also defined in a unified manner. In hibernate 3, lazy load can be defined at the column level.

The problem is that the above definitions are in the HBM file,The loading policy of each object can be defined only once.. Instead of JDBC,Select different result columns based on different situations.

A problem is that the information is incomplete. For example, if the product only has a serial number and a name, it cannot be expressed in a pure object-oriented environment, the Component solution provided by Hibernate is not very good either.

3. Transparent persistence-some temporary operations on pojo will also be persistent
Because persistence is transparent, it is easy to misuse and some temporary operations on pojo will be accidentally stored in the database. In addition, the session and transaction chaos make it easier to figure out what happened without running DML statements in JDBC.

Besides, not everyProgramMembers can get used to the new transparent and persistent environment and have a profound understanding of the persistence policies of the orm system. In addition, these policies and the frameworks that integrate them, such as spring, are often changed without prompt during the upgrade !!!

Therefore, every team that uses ORM will always have a few days in the project process ......