?

?

There's been a certain amount of noise recently surrounding simple JDBC frameworks like iBATIS. I've liked the idea of iBATIS myself, for use in applications which don't need an object-oriented domain model, and don't work with deep graphs of associated entities in a single transaction. A JDBC framework also makes good sense if you are working with some kind of "insane" legacy database; ORM solutions tend to assume that associations are represented as nice clean foreign keys with proper referential integrity constraints (Hibernate3 much less so than Hibernate 2.x).

?

Some people even suggest that JDBC frameworks are a suitable alternative to ORM, even for those systems to which ORM is best suited: object-oriented applications with clean relational schemas. They argue that you are always better off with hand-written SQL than generated SQL. Well, I don't think this is true, not only because the overwhelming bulk of SQL code needed by most applications is of the tedious kind, and simply does not require human intervention, but also because a JDBC framework operates at a different semantic level to ORM. A solution like iBATIS knows a lot less about the semantics of the SQL it is issuing, and of the resulting datasets. This means that there is much less opportunity for performance optimizations such as effficent caching. (By "efficient", I am referring mainly to efficient cache invalidation strategies, which are crucial to the usefulness of the cache.) Furthermore, whenever we have seen handwritten SQL, we have seen N+1 selects problems. It is extremely tedious to write a new SQL query for each combination of associations I might need to fetch together. HQL helps significantly here, since HQL is much less verbose than SQL. For a JDBC framework to be able to make the kind of optimizations that an ORM can make, it would have to evolve to a similar level of sophistication. Essentially, it would need to become an ORM, minus SQL generation. In fact, we already start to see this evolution taking place in existing JDBC frameworks. This begins to erode one of the stated benefits: the claimed simplicity.

?

It also raises the following interesting thought: if, by gradually adding stuff, a JDBC framework will eventually end up as ORM, minus SQL generation, why not just take an existing ORM solution like, ooh, um ... Hibernate, maybe ... and subtract the SQL generation?

?

The Hibernate team has long recognized the need to mix and match generated SQL with the occasional handwritten query. In older versions of Hibernate, our solution was simply to expose the JDBC connection Hibernate is using, so you can execute your own prepared statement. This started to change a while ago, and Max Andersen has recently done a lot of work on this. Now, in Hibernate3, it is possible to write an entire application with no generated SQL, while still taking advantage of all of Hibernate's other features.

?

Do we really expect or intend people to use Hibernate in this way? Well, not really - I doubt there are many people out there who really enjoy writing tedious INSERT, UPDATE, DELETE statements all day. On the other hand, we do think that quite a few people need to customize the occasional query. But to prove a point, I'll show you how you can do it, if you really want to.

?

Let's take a simple Person-Employment-Organization domain model. (You can find the code in the org.hiberna

推荐阅读更多>

1. 数据库有几种目录
2. Redis学习笔记（1）
3. SQL 时间格式化函数
4. oracle startup 异常诊断
5. 关于数据库衔接
6. sendTextMessage后信息储存到系统数据库
7. 关联关系 一个表的ID赋值到另一表的联系关系ID
8. Oracle跨数据库查询并安插
9. HBase的API接口打包及调用
10. ORA的DBLINK兑现数据的同步功能
11. 一种复杂方便的权限管理方法--运用菜单
12. DBDesigner4联接mysql出错的处理
13. 怎样将Excel中的数据导入到SQL Server 2000数据库中
14. Android 开发联接 MySQL 数据库
15. hibernate处置批量更新和删除
16. SQLite数据库 hibernate配备方言
17. oracle分组函数的引见（五）
18. 数据库名、实例名、数据库域名、大局数据库名、服务名（转）
19. Oracle 会合操作符 UNION/UNION ALL/INTERSECT/MINUS的用法
20. Oracle创造用户、表空间、导入导出、命令