The talk of Java Learning (12)--orm

This is the last piece of Java talk, to the ORM framework of the end of the discussion, but also to the last part of the Java EE to cover, the reason is so late to sum up the ORM this aspect, one is the author of these two weeks busy, on the other hand also want to finish, carefully first study ORM framework technology, Don't want to rush through the motions.

In fact, the specification guide for Java EE has included some object persistence techniques, such as JDO (Java Data object), a new specification for the persistence of a java-based object, a standardized API for accessing objects in a data warehouse, providing transparent object storage for developers, Storing data objects completely requires no additional code (such as the use of the JDBC API). These tedious tasks have been shifted to JDO product providers, freeing developers to focus their time and effort on business logic. In addition, JDO is flexible because it can run on any underlying data. JDBC is more generic to relational database (RDBMS) JDO, providing storage functionality at the bottom of any data, such as relational databases, files, XML, and Object Databases (Odbms), and so on, making applications more portable. If we want to understand the technology of object persistence, we have to ask ourselves one question: why is it that traditional JDBC can no longer satisfy everyone's needs?

I think it is best to use JDBC to really write a program to really realize the benefits of ORM, the same truth, really take servlet/jsp did project can realize the struts, spring and other frameworks convenient place. Fortunately, the author of both have experienced, with the chaotic embedded Java code JSP plus servlet forward to write a complete Web project, but also with JDBC built a complete C/s project backstage. So it is ugly to look back at the old code, so that the new framework is more able to appreciate the superiority of their thoughts and fulfillment. ^_^

Back to the point, let's look at why we need to develop from JDBC to ORM. In short, the traditional JDBC to spend a lot of repetitive code in the initialization of the database connection, every additions and deletions to obtain connection object, initialization statement, Execution gets resultset and then encapsulates its own list or object, which creates a lot of redundant code in each data access method, plus a lot of transaction control and log records, taking into account security. Although we have learned the design pattern, we can define factory to help reduce some of the duplicated code, but we still can't avoid the problem of redundancy. Secondly, with Oo thought, even the typical process language Perl, and so on, and the OO shell, not to mention the Java Complex database access persistence technology? The result of object-oriented programming is to find a bridge, so that the data stored by relational database can accurately map to Java objects and then design objects and methods for Java objects, if we treat database table as class,record as instance, You can write data-tier code entirely with object-oriented ideas. As a then, the concept of Object relationship mapping began to be universally appreciated, although it was already proposed early.

Shortcomings we have probably clear, then how to improve it? The first thing we need to solve is how to prepare the perfect map to the object schema from the data schema, provide management of the lifecycle of the database connection object, control the different granularity of the transaction, and provide the XML, Support for configurable files such as properties. So far, there are many frameworks and techniques that are trying to do so. For example, it appears to be a encapsulated, managed EJB, an early appearance of the Apache OJB that is now not developed and upgraded, the first to support manual SQL Ibatis, and the admittedly very good hibernate, and so on. Before I introduce them separately, I would like to stress what these frameworks are trying to do:

After all, there is a big difference between Java object and every record in a database, which is that there is no Boolean type for db. And Java also had to use encapsulation class (Integer, double, etc.) in order to be able to map the case of NULL in the database, after all, primitive type is not null value. There is also a more obvious problem is that the database has a primary key and foreign keys, and Java still only through the basic types of the corresponding field values, can not specify unique characteristics, not to mention foreign KEY constraints, transaction control and cascading operations. In addition, the Java object preset a field value to fetch the database records, whether in such a record is not guaranteed. If you really want to design a full map, what about the static of Java being shared by all the objects? How to show in the database ...

We can see a lot of problems like a big mountain in front of those framework designers, they are not without solutions, but from a different point of view, will get a lot of different solutions, the question is which one should be taken? Even until the actual design of the production to use, can confirm the original idea is really able to bring more benefits to project development. The author cites a document that mentions the characteristics of a robust persistence framework:

A robust persistence layer should support--

1.Several types of persistence mechanism

2.Full encapsulation of the persistence mechanism.

3.multi-object actions

4.Transactions Control

5.Extensibility

6.Object identifiers

7.cursors:logical connection to the persistence mechanism

8.proxies:commonly used the results of a query are to is displayed in a List

9.records:avoid the overhead of converting database Records to objects and then Records

10.Multi Architecture

11.Various database version and/or vendors

12.Multiple connections

13.Native and Non-native drivers

14.Structured query L