Hibernate and Apache OJB relative, such as "one-stop" ORM solutions, ibatis is a kind of "semi-automatic" implementation of ORM.
The so-called "semi-automatic," probably understand a bit jerky on. Taking an overview of the current mainstream ORM, whether Hibernate or Apache OJB, all of the database structure to provide a more complete package, provides a POJO to the database table from a complete set of mapping mechanism. Programmers often need a good definition of POJO to the database mapping table can be provided through the Hibernate or OJB persistence layer of the methods to operate. SQL programmers do not even need to master the, Hibernate / OJB formulate storage based on logic, automatically generate the corresponding SQL and JDBC calls to the implementation of interfaces.
In most cases (especially for new projects, the development in terms of the new system), such a mechanism always work, dominate the world as seen great momentum. However, in some specific circumstances, such a one-stop solution is not very good. The author of the system in the process of consultation, usually encountered in the following circumstances:
1. System, some or all of the data from an existing database, in security reasons, only a few of the development team to provide Select SQL (or stored procedure) to obtain the required data, the specific structure of the table is not open.
2. Called for the development of norms, all related to business logic part of the database operations, must be stored in the database layer from the process of implementation (on the job by the author for the financial industry, Industrial and Commercial Bank of China, Bank of China, Bank of Communications, both in the development of norms strictly specified)
3. Deal with the enormous amount of data, an extremely demanding performance requirements, which often means that we must pass through highly optimized SQL statements (or stored procedure) to achieve the target performance-based design system. Faced with this demand, once again raised his machete Hibernate, they found no longer a sharp blade, or even can not be used, it is regrettable that? Trance, the preparation had no choice but to re-JDBC death in order to work out ... ... one stroke, it is somewhat bleak, the direct use of JDBC database operation is in fact a good choice, but the database access code and excessively bureaucratic, boring read operation so that the field tired of people.
"Semi-automatic" in ibatis, has just solved the problem.
The "semi-automatic," and so on are relatively Hibernate database provides a comprehensive package mechanism, "fully automated" ORM implementation, the "automatic" ORM implementation of the POJO and mapping between database tables, as well as automatic generation of SQL and implementation. Ibatis and the focal point, is to POJO and mapping relations between SQL. In other words, ibatis and programmers will not be automatically generated at run-time SQL implementation. Specific SQL programmers required to prepare, and then through the mapping configuration file, the SQL required parameters, and return the results of field mapping to a specific POJO.
Ibatis provided the use of ORM mechanisms, implementation of business logic in terms of personnel, in the face of the pure Java object, this layer with ORM in terms of implementation through the Hibernate basically the same, and for the specific data manipulation, Hibernate automatically generates SQL statements , and ibatis requires developers to write specific SQL statement. Hibernate and other relatively "automatic" ORM mechanism, ibatis to the workload of SQL development and database portability on concessions for the system design provides greater free space. As "automatic" ORM implementation of a useful supplement, ibatis emergence seems particularly meaningful.







