IT technology changes with each passing day, the emergence of new technology dizzying, IT seems that every day in the production of new terms. At the end of the day, however, IT is all about collecting data and presenting IT to customers in the form they want. Therefore, data access technology has become an eternal topic. In the open world of Java, database access technologies are multifarious and varied. We will also cover the main database access technologies in the Java world.
First list of heroes
1.JDBC directly access the database
2.EJBentitybean.
3. JDO technology.
4. Third-party O/R tools, such as Hibernate which is currently popular, and others such as Castor and Toplink.
Let’s start with the oldest JDBC. From the day Java was born, this man began to appear on the stage of history. Java can have today’s scenery, JDBC can be said to be indispensable. Along the way, it’s now JDBC3.0. In the absence of JDBC, access to the database that is the eight imfairy crossing the sea, each database manufacturers have their own set of API, bitter bitter developers. Change the database, that program will be changed beyond recognition. The introduction of the JDBC specification announces to the world that there is a standard universal interface to access relational databases. The JDBC standard is supported by almost every database vendor, and it’s hard to find a database that doesn’t have JDBC support. Once published, the JDBC specification was an unprecedented success and quickly became the standard for Java to access databases. JDBC success lies in its standardized unified standard interface, only need to master the standard SQL language can access a variety of different databases. Portability between the database and Java has been Shouting slogans CompileOnce, Runeverywhere summit. JDBC is still the cornerstone of Java access to databases today. CMP,JDO and Hibernate in the final analysis just better encapsulate JDBC and provide a more powerful interface at a higher level. Then talk about how JDBC directly accesses the database to implement Java persistence.
This method is simpler and more direct than CMP, especially for small applications. For example, if I wanted to write a simple message board application, there would be no need for session beans, EntityBeans, and both home and remote interfaces. Direct JDBC, write SQL statements. Compared to other persistence techniques, JDBC directly accessing a database requires a programmer to worry a little bit more. You have to care about transaction, you have to care about connection pooling, you have to write a lot of getSet methods, and you have to stuff SQLselect values into your JavaObject one by one. Or pull out the javaObject values one by one, use SQLinsert to the database, and do O/Rmapping completely manually. In order to overcome these shortcomings, CMP,JDO and so on began to appear on the historical stage.
DO is best known for its ease of use. No need to write lots of useless interfaces, no need to inherit special classes, all you have to DO is enhance your class file. With JDO, we can say that our Java program under the real OO, we do not need to care about what tables in the database, access are javaObject as the object, all database tables are automatically generated. This, too, is a revolution. Prior to this, the DatabaseSchema design was a major part of the project design phase. Now, with JDO, you don’t need database design at all. What about your DatabaseSchema? JDO will automatically generate a database table based on your Class. In a word, cool! From the point of view of database portability, JDO is also an obvious advantage, I have used Kodo and Genie, a few simple applications to change the database in addition to a JDBCdriver, change the database URL, without any changes to the program. This is again at a disadvantage for EJBs. From the perspective of family background, JDO was also born into a famous family and was under the management of JCP from the very beginning. From the perspective of enterprise-level support, it can work well with session Beans. For enterprise-level development, the way of Sessionbean+JDO is a strong competitor of the way of Sessionbean+ Entity. In may, IBM,Oracle, and Bea voted against JDO2.0. But on second thought, it’s understandable that this is not a major flaw in JDO’s own technology, but that JDO has moved the cheese of these giants. Bea,IBM’s leading application servers, WebLogic and WebSphere, had invested heavily in EJB and could not afford to see JDO cannibalize the EJB market. Oracle, which still sells its own O/R tool, Toplink, can’t wait to see JDO go from strength to strength. However, no matter how great the company was, he could not stop the wheel of history. Finally, JDO2.0 was approved by an absolute vote (12:3).
There are other scattered jianghu Java persistence technologies such as Hibernate, Castor, Toplink, although they no royal descent, but strength is also be reckoned. Take Hibernate as an example, it is the best Java data access tool selected by JavaWorld in 2003, and it can be said that it is very popular now. Castor and Toplink have been around since before JDO came along. At present also occupies a certain market. These third-party tools are functionally similar to JDO, with different apis. This is one reason why the JDO specification has become more and more popular. Each of these third-party O/Rmapping tools has its own niche. Hibernate, for example, is the signature of OpenSource, which supports almost all the databases you can see in the world, and is very well-documented. Toplink has a long history and is the biggest tree in Oracle. Currently, these tools are also a significant market for Java database access. Personally, with the improvement of JDO specifications and the popularity of JDO products, this part of the staff may gradually withdraw from the historical stage in the future. However, from Hibernate’s current momentum at the peak of the day, it seems that this sentence is premature.
Arguments about the merits of these technologies have never ceased from the day they were born, and the factions have never been able to convince each other. For us app developers, it doesn’t make much sense to argue about the pros and cons of the technology, regardless of the application. Or as the saying goes, there is no best, only the most appropriate. When we do development, we can choose a technology that is most suitable for our application, and that is enough. In general, JDBC is rDBMS-oriented and is well suited for relational database pattern-driven applications such as tabular data statistics and reporting generation. EJB technology is centered around J2EE application servers, and if your application really needs flexible declarable transaction boundaries, high volume access and uninterrupted service, and clusters of application servers, choose EJB. JDO is object-oriented and is preferred for applications centered on domain objects, including graphs and tree models.