private SQLAccessor<UserForm> action = new SQLAccessor<UserForm>();

//添加操作

public int insert(UserForm userForm) throws DBProcessException, SQLException{

return action.execute(StmtFactory.getSql("user.inset"), userForm);

}

//更新操作

public int update(UserForm userForm) throws DBProcessException, SQLException{

return action.execute(StmtFactory.getSql("user.update"), userForm);

}

//删除操作

public int delete(UserForm userForm) throws DBProcessException, SQLException{

return action.execute(StmtFactory.getSql("user.delete"), userForm);

}

//查询操作

public UserForm query(UserForm userForm) throws DBProcessException, SQLException{

return action.query(StmtFactory.getSql("user.query"), userForm, UserForm.class);

}

//分页查询

public Result<UserForm> result(UserForm userForm) throws DBProcessException, SQLException{

return action.result(StmtFactory.getSql("user.result"), 1, UserForm.class);

}

favoor标签使用（动态分页查询）：

<f-sql:result var="result" beanClazz="net.favoor.demo.UserForm" currPage="currPage" where="true">

<f-sql:sql key="user.split.page">

<f-db:format type="String">{0}</f-db:format>

<f-db:format type="int"><f-db:endRow/></f-db:format>

<f-db:format type="int"><f-db:startRow/></f-db:format>

</f-sql:sql>

<f-db:dynamicFormat prepend="AND">

<f-db:isNotEmpty property="email" prepend="AND">

EMAIL LIKE ?

</f-db:isNotEmpty>

<f-db:isNotEmpty property="nickname" prepend="AND">

NICKNAME LIKE ?

</f-db:isNotEmpty>

</f-db:dynamicFormat>

<f-db:params>

<f-db:param type="string" dynamicProperty="email">%<c:out value="${param.email}"/>%</f-db:param>

<f-db:param type="string" dynamicProperty="nickname">%<c:out value="${param.nickname}"/>%</f-db:param>

</f-db:params>

<f-sql:count where="true">

<f-sql:sql key="user.count"/>

</f-sql:count>

</f-sql:result>

favoor 目前缺乏对cache的支持，准备套用ejb 3.0的方式使用annotation方式，希望大家探讨，favoor在整理完代码后将开源

使用裸露sql语句的弊端！

1：严重绑定数据库！

2：丧失重构

3：暴露数据库结构

4：chache问题

5：migration 问题

6：接口管理困难

7：reuse不大

1：使用sql，必然严重绑定数据库结构，虽然说数据库结构相对稳定，但是也有变动的可能性，添加新表和级联更是经常发生，如果使用sql，意味着每次变动都有可能对业务做大量修改！

2：丧失重构，业务层的重构讲究业务逻辑和持久逻辑的松耦合，使用sql，注定接口oo性不强，业务接口会和持久接口匹配混乱！彻底丧失重构的可能性。

3：严重暴露数据库结构！ －－显而易见的问题，有安全隐患

4：针对sql的接口没有办法提供细力度的缓存。无法适应高性能，高复杂性的重用！

5：项目转平台的时候，由于没有o/r的支持，sql对数据库的依赖和接口重写带来的效益损失不可估计！

6：作过持久的人都知道。使用sql 模版的问题！不说了

7：自己做的轮子到底缺乏历练，一些高级特性，比如继承，模式都办法使用，必然会导致接口多而杂，有很多接口功能类似但是却自己做自己的事，性能损失很大

反正使用sql模版开发小中型以上的项目都是不可能的，拿钱当水漂！而且关于事务控制和线程上的台阶比任何一个o/r工具都要高很多！

但是做为一个扩展支持还是不错的，毕竟o/r的query远没有sql强大，在一些统计需求里sql还是必须的