J2EE企业级软件架构越来越鼓吹N层体系架构，很多架构师陷入了为架构而架构的怪圈，引入越来越多的没有测试过的开源组件，增加越来越多的适配层，导致系统底层架构没有人能驾驭，平台性能问题一旦出现，就找借口是数据量大、并发访问高，通过加硬件救急！
本文先对Java平台SQL查询语句集中管理提出一个实用方案。其背景是目前的J2EE架构大量使用hibernate等ORM框架，SQL/HQL分散在各模块的Java类中，而且很多采用拼SQL的方式（非预编译即PreparedStatement方式执行），导致至少带来如下两个严重问题：
?
- SQL性能无法预测，至少运行前无法检测（目前大部分现象都是出现性能问题到生产环境采集SQL，但是由于业务的周期性，存在SQL的覆盖率问题，另外采集毕竟是个相对专业的技术活）；
- 查询逻辑变化，由于SQL/HQL散落在代码的各个角落，必然导致维护起来很麻烦，且数据库设计人员无法知道程序员的SQL语句是否正确；
- 不支持热部署，尤其是在集群部署环境下，部署工作运维人员头疼！
解决思路我画了一个图：
?
大概描述一下：
?
- 由core_query表统一管理SQL查询语句；
- 开发一个管理界面维护core_sql表，并更新至分布式缓存；
- 应用启动时从core_query表加载SQL语句至缓存，应用从缓存中获取SQL语句；
- SQL语句采用命名查询的概念，即每条SQL语句都有一个唯一的名称，可以采用名称空间命名；
- 应用调用采用spring提供的jdbcTemplate的queryForList(String queryName, Object[] args)方法进行查询，返回类型为：List<Map>，尤其在jstl，显示数据与List<User>完全一致；
- 每条SQL语句可以扩展支持查询缓存；
实现目标：
- 事前准确评估性能：所有查询语句统一管理，便于在设计开发阶段准确评估性能问题，避免系统运行过程中出现的性能瓶颈；
- 查询逻辑变更后维护方便；
- 支持热部署，支持集群环境热部署；
一些经验：
- 所有select语句（除通过主键load单条记录外），全部采用命名查询，由core_query表统一存储管理；
- 单条记录的insert、delete、update和load，可以采用ORM技术，在dao层完成数据库读写；
- 批量的delete和update语句，采用命名查询方式；
- 专注查询，避免了 SQL 或者 HQL 代码分散于整个应用程序中的情况；
待续...
?
1 楼 iwangxiaodong 2012-10-09
我用的是MyBatis,它采用了xml来统一管理SQL语句,而且,将xml文件纳入Tomcat监视范围可热插拔修改!
2 楼 hxl1013 2012-10-09
之前用过将SQL集中在properties中，和你的差不多意思~只是存储目的地不同而已