Ibatis VS Hibernate

Recently, in the Javaeye forum, saw Ibatis and hibernate posts, look at the heart feel oppressed, do not say unhappy, here, I would like to further refine:

1. The complexity of the library table depends first on the requirements, not on the design, on the design, but also on the standard of the design of the library, from the three paradigms of the Basque world, in principle. Can not say that use of hibernate, their own library table design ability is strong. Not to use Hibernate, to blindly criticize complex relationship is wrong. The complexity of relational design depends first on whether there is a complex requirement, and secondly on the ability of the designer.

2. As long as you're using a relational database, you have to understand why it's called a relational database, not an object-oriented database, where you take responsibility for the idea of object-oriented, the design of the library table, and later maintenance and tuning, and you can't let developers wipe their butts for early decision makers. I have seen some people, playing Oo and the banner of extensibility, abruptly put a table, split into three tables, and these three tables, originally, only need to add a type of field, and then do some redundancy, can be a table. Now the query, but also to the three tables union to check. When the requirements change, add a field, not only to change three classes, but also to change three tables, it is incest.

3.one-one's library table design, for DBAs, is not a best practice design. Can not for hibernate, deliberately put large table into small table, and then use a few small classes, made one-one mapping relationship. Integrity, is not a casual segmentation, after all, developers in debugging, testing and maintenance, more like to look at the data in the database, originally a SQL, on the detection, now to a number of tables to check.

4. Delete and change the entity maintenance

Ibatis than Hibernate, to say the truth, now let me write SQL to maintain a many-to-many relationship of the entity maintenance, I have to consider the half, don't write code.

5. Do you need to write native SQL?

First of all, you have to confirm that your project requirements do not need to write native SQL, and then say Ibatis and hibernate good or bad, in writing native SQL, especially dynamically generated sql,ibatis than Hiberante have a fight, ibatis like a template, Write SQL in the configuration file, centralized configuration, especially convenient for the technology leader to monitor the project members write SQL Good or bad, and there is no learning curve, write SQL is finished.

Some would say that hibernate also supports writing SQL, but in writing code, it loses the simplicity of the DAO that was originally based on Hibernate. The DAO is not concise at all, and if you put the code of the dynamically spelled SQL in the DAO, the DAO will be flooded with a lot of if. Else.. Such statements, a lump of a lump, very spectacular.

Others would say that Hibernate also supports named queries, which write SQL in the mapping file, but named queries only support placeholder-invariant situations, that is, where a =? and B =? And c=?, is three question mark, is three question mark, when passes the parameter, one less is not good. However, many of the project query, are dynamic, that is, the user chose the query conditions, will generate this placeholder.

Hibernate can't do that.

Some people will say, I use hibernate to write a frame, also can do, that you write may be better than ibatis, also may be poor, you want to build wheels, who will stop.

5. Tuning

Early tuning, some bad SQL, in fact, in the code review phase, just look at the ibatis SQL configuration file can be killed, if the use of hsql, may not be found, because it is not only hidden in the code, sometimes, but also need to run the program, through the day The log prints out the SQL or looks through other tools such as P6spy.

Later tuning, since it is tuning, I think must be met the bottleneck, you might want to do redundancy on the library table, you might want to check for bad SQL, you might want to modify the code, you might want to use some of the tuning methods on the DBA level, then the advantages of ibatis, such as adding temporary tables, The middle table, add redundant fields, and so on.