Java Database access Technology _jsp programming

It technology is changing rapidly, the emergence of new technology is dizzying, it seems that every day in the emergence of a term. But ultimately the value it has to achieve is data collection, which is then presented to customers in the form of a customer's desire. Therefore, data access technology has become an eternal topic. In the open world of Java, Database access technology is diverse and varied. We have also come to regaling the mainstream database access technology in the Java world.

First, list the heroes.

1. JDBC Direct access to database
2. EJB entity Bean.
3. JDO technology.
4. Third-party O/R tools, such as the current hibernate, others such as Castor, TopLink.

Let's talk about the oldest JDBC. From the day Java was born, the man began to embark on the stage of history. Java can be so beautiful today, JDBC can be said to be not the end of the work. All the way, now is JDBC3.0. In the absence of JDBC, access to the database that is eight Immortals crossing, recount, the database vendors have their own set of APIs, suffering the developer. Changed the database, the program to change is beyond recognition.

The introduction of the JDBC specification, declares to the world that there is a standard universal interface for accessing the relational database. The JDBC standard is supported by almost any database vendor, as if it's hard to find a database that is not supported by JDBC. The JDBC specification, once released, was an unprecedented success and quickly became the standard for Java to access the database. The success of JDBC lies in its standard unified interface, which requires only a standard SQL language to access a variety of different databases. This portability between databases and Java has been shouting slogans compile Once, Run everywhere echoes. JDBC is still the cornerstone of Java's access to databases today, and CMP, JDO, and hibernate are simply better at encapsulating JDBC and providing a more powerful interface on the top. Then say that JDBC directly accesses the database to implement Java persistence.

This approach is straightforward compared to CMP, especially for small applications. For example, I want to write a simple message version of the program, there is no need for session beans, entity beans, but also the home interface is a remote interface, layer by layer. Direct JDBC, write SQL statement. Compared to other persistence technologies, JDBC's direct access to the database requires programmers to worry about a lot more, you have to care about transaction, you care about the connection pool, you have to write a lot of Get set method, put the value of SQL select a one into your Java object, or the value of Java object is taken out of one, with SQL INSERT into the database, completely manually for O/R mapping. To overcome these shortcomings, CMP, JDO, and so on began to embark on the history stage.

The following EJB debut, EJB as a core part of the Sun Java EE system, is the first choice for enterprise-level development pushed by Sun, and EJB entity is still the most recommended Java persistence technology in the Sun Java EE White paper. Entity Bean, as part of the EJB specification, is also one of the most controversial techniques in the EJB specification, along with the EJB specification, which has gone through several ups and downs. At present, the draft EJB3.0 norms have been introduced, http://jcp.org/en/jsr/detail?id=220.

From the point of view of the birth of the family, EJB is the root of the Miao red, the norms under the JCP management, with a super luxurious team of experts, Sun, IBM, Oracle, Borland, Bea, SAP, Jboss, Apache Software fund and so on. From this point of view, choose it as an enterprise-level development, technical support should not worry. Of course, it's also expensive to ask IBM, BEA, and so on for a project consulting price. From the point of view of providing the function, the EJB entity experienced the ejb1.0,ejb1.1,ejb2.0, the function is also more and more perfect. Includes perfect transaction support, EJBQL query language, transparent distributed access, and so on. However, as a heavyweight technology, the entity Bean's performance is not very satisfactory, which has become a controversial focus, I do not know whether the situation will be improved after 3.0.

Another, although it is powerful, but for ease of use, it is not flattering, write a simple bean, also have to home interface, remote interface, to add 2.0 after the addition of the local interface, so a large range, enough to let the Java beginners discouraged. But this has become a powerful and technologically advanced "corroboration" of EJB function for some time.　Remember that years ago just graduated from the Matrix, EJB application in the domestic still relatively few, there is no one in the company to study the problem of why EJB, anyway, the project is the EJB with the Cow project, the EJB is the cow, the group of Brothers to the EJB team are walking up the head, speak more than I am still in JDBC, The people of SQL have to be taller than two voices. EJB technology is currently entrenched in the enterprise-class application of most of the Jiangshan, the boss position in a short period of time difficult to defend.
Following the new generation of JDO on the grand debut, Jdo is definitely a super young player, JDO1.0 is only 20,024 months before the release. 20,035 months, 1.0.1, the latest 2.0 draft has been released. For this 2.0, the lake on the discussion can be said to be "bloody", the two large corps, JDO Corps and EJB Corps is full of the fight. Interested may wish to see, there are no lack of heavyweight figures. From this point of view, it can have such a big impact on the EJB, it is enough to show that this newborn calf is indeed extraordinary. The advent of JDO brings many new features to Java data persistence, especially as it compensates for the inherent weakness of EJB for OO programming, which JDO provides complete OO support, inheritance, and polymorphism. Jdo and EJB ratios belong to lightweight tools without container support. Unlike EJB, you have to have a whole weblogic, websphere or something.

JDO's easy to use is the most praised, do not need you write a lot of useless interfaces, do not need you to inherit any special classes, the only thing to do is to your class file to do a enhance. With JDO, we can say that our Java program is really oo, we do not have to pay attention to the database what table, Access is in Java object, all database tables are automatically generated. This can be said to be a revolution.

Prior to this, the Database schema design was a big play in the project design phase. And now with JDO development, no need for database design. What about your database schema? Is your class, JDO will automatically generate the corresponding database table according to your class. A word, cool!　From the database portability point of view, JDO is also an obvious advantage, as I used Kodo and Genie, a few simple applications to change the database in addition to a JDBC driver, change the database URL, do not need to make any changes to the program. This is a disadvantage for EJBS. From family background, Jdo is also a born family, from the beginning of the JCP under the management. With enterprise-level support, it works well with session beans, and for enterprise development, session Bean + JDO is a powerful competitor to the session bean+entity approach. Although there are so many advantages, but its development path is not smooth, this is not, this May JDO2.0 vote, IBM, Oracle, Bea three big Giants also voted against. But just a little thought, it is understandable that this is not a major flaw in JDO's own technology, but Jdo's move to the cheese of these giants.

Bea, IBM is the industry's most famous application server, WebLogic and WebSphere, on the EJB is dropped the money, they can not watch jdo to eat into the EJB market. And Oracle, still selling its own O/R tools TopLink, looking at Jdo increasingly strong, he can not hurry. However, the company again cattle, he also can not stop the history of the wheel bar, the final JDO2.0 vote or the absolute number of votes (12:3) passed.

There are other scattered in the lake of Java technology, such as Hibernate, Castor, TopLink, although they do not have royal lineage, but the strength is not to be overlooked. Take hibernate, is the Javaworld selected the 2003 Best Java data Access tools, is now a great call. And Castor and TopLink are also a long history, before Jdo was born, they were mixed up in the lake. At present also occupy a certain market. These third-party tools are functionally similar to JDO, except that their APIs are different. This is one of the reasons for the increasingly high voice of JDO specifications. These third party O/R mapping tools can be in the River Lake foothold, and indeed have their own extraordinary place. such as the Hibernate brand is open Source, support almost the world can see most of the database, and the document is also very complete. TopLink, it is a long history, and the list of Oracle this big tree. For now, these tools also occupy a very small market for Java database access. Personally feel that, with the JDO specification is not perfect, jdo product popularization, this part of the people may gradually withdraw from the stage of history. However, judging from the momentum of Hibernate's current heyday, it seems too early to say this sentence.

The pros and cons of these technologies have never ceased since the day they were born, and the factions have never been able to convince each other. For our application developers, it doesn't make much sense to argue about the pros and cons of applying pure technology. As the saying goes, there is no best, only the most suitable. It is enough that we can choose a technology that is best suited to our application when we do development. In general, JDBC is geared towards RDBMS and is more suitable for relational database mode-driven applications, such as statistical table data, generating reports, and so on. EJB technology to the Java-EE application Server as the center, if your application does require flexible and declarative transaction boundaries, the need to support high-volume access and uninterrupted service, the application server cluster, then select the EJB bar. JDO is the object-oriented, JDO is the first choice for domain-centric applications, including graphs, and tree model applications.