想讨论下数据库持久层的必要性
开发SSH时，往往写完PO类，设置好映射的数据库字段时，写对应的DAO的方法，再写所谓的DTO，设置好所有返回前前台的结果集，无谓就是省着写SQL了而已

如果我直接在ACTION中写SQL去操作数据，查询出来的结果集直接通过封装好的JDBC方法按照字段名转换成JSON对象传递给前台，前台通过EXT去的STORE去解析对应的字段，这样完全可以省略PO DTO等等模式 如果不使用EXT，也可以传递到前台一个LIST，每条记录一个MAP，前台用过JSTL也是完全可以解析展示的。

如果说没有写DAO层会造成一些复用的麻烦，也可以把所有的SQL方法写到一个DAO类中，完全也能够实现DAO操作相同数据库方法的复用

个人觉得比写PO DTO啥的方便，而且HSQL写起来也不通俗 效率也低，一些复杂的SQL往往还不支持
------解决方案--------------------
我也曾经考虑这样做，而且代码都写好了
后来总结了一下，
这样做可以省略不少代码，省了很多jar和框架，ssh通通不靠边了。
但是这样做，失去了mvc模式，失去了面向对象的概念，不能很好的分层，后期维护很困难，
不利于数据库移植，不灵活！

我们目前是这样做的：
根据模板连接数据库生成映射文件和实体类，自己封装了一个SqlUtil类，泛型操作，dao和service就不用了，一个servlet解决所有http请求，比如：

SqlUtil<User> sqlUtil = new SqlUtil<User>();

User user = new User();

user.setName("张三");

user = sqlUtil.insert(user);

Long id = user.getId();

user = sqlUtil.getById(id);

user.setAge(20);

user = sqlUtil.update(user);

user = sqlUtil.delete(user.getId());

List<User> users = sqlUtil.getDataList("select * from t_user where age >= ? order by id", new Object[] { user.getAge() });

好好运用javax.sql.DataSource这个接口和连接池，合理利用缓存(cache)，其效率比hibernate或ibatis 要高的多！
------解决方案--------------------
这个想法很好!
我是这样觉得的,ssh只是框架，框架其实是服务于业务的，那么也就是说什么样的业务决定要用什么样的框架。
如果这样看的话，其实怎么做，做成什么样，不是由框架决定的，而是由业务决定的。
所以，我们在设计系统或是产品技术框架的时候要综合考虑，技术体系的确定由方方面面决定。
例如：产品的维护、产品性能、产品的扩展性等等。所以用什么样的层次来实现都没有问题，关键有产品决定。
当然，一般ssh适合做大型的产品，模块化的需要有很强扩展性的产品，业务角度来看需要层次区分明确的产品。
并且不光是使用数据持久还有文件持久地系统，业务逻辑处理相当多的产品。
直接使用action处理数据，前台使用EXT等这样的框架是适合对业务逻辑不是很复杂或是不怎么需要业务逻辑处理的产品，直接和数据库打交道的产品特别适合使用这样的方法，不需要分那么多层。
希望这些卓见可以帮到你！