介绍一种免xml配置的持久层实现快速开发的框架。

Speed 快速 J2EE 开发框架
Speedframework(http://sourceforge.net/projects/speedframework)是一个完全基于JDBC开发的轻量级持久层框架. 它可以直接调用SQL,也可以直接对POJO进行CRUD操作,代码与ORM相当.调试方便,不用配置,内置JCS缓存,能有效降低数据库压力,它具有以下特点:


1.免配置持久层，免配置可以减少开发中配置带来的烦恼，调试带来的烦恼。
2.完全是jdbc封装操作，性能完全没问题。
3.jcs cache实现，对于数据库操作对象缓存减轻数据库压力。
4.自带分页组件，完全可以直接传入一条sql即可完成困难的分页逻辑，可以由客户自定义。
5.结合表、视图实体逻辑设计模式可以实现xp开发。
6.speed能自动识别表字段pk的自增主键，并可以返回自增字段值。
7.实现了jdbc的批处理封装，存储过程调用等jdbc api常用的封装。
8.降低了入门门槛，有利于初期开发和中后期维护，适用于开发程序员经常更换的团队。

不知和IBatis有无区别和特点？或者能弥补iBatis等一个关键的缺陷，这样才避免发明新轮子。

> 不知和IBatis有无区别和特点？或者能弥补iBatis等一个关键
> 娜毕荩庋疟苊夥⒚餍侣肿印?>

谢谢banq 支持。我们把项目开源的目的也是希望大家减轻工作量。

speed框架的pojo都通过反射机制直接映射表结构，只需要把pojo和vo定制好后开发调试都简单，iBatis麻烦在于程序代码开发同时还要配置xml内部的sql。speed框架可以与任何当前如spring等的AOP框架结合使用。

利用表、视图对象逻辑的设计模式+speed框架可以进行xp快速开发。

基本上一个刚招进来懂得struts的程序员，通过15分钟简单的培训后，在15分钟内即可完成对于一个表不复杂逻辑的增、删、查、改、分页等功能。

目前已经使用speed一年了，我们基本没有加班。而且是1－1。5模块/1天/1人。

无XML配置是快速开发的一个条件，这个思路对了。
现在很多框架都是大佬级别人用的，动不动就来个xml cong,号称方便配置，我操，这些人当每个人都象他一样精力旺盛慢慢去搞配置。

个人认为有没有XML倒不是最关键的，如果有合适的IDE,自动搞定就无所谓了.最怕的是让我来手写,近视眼,怕怕...

如果遇到speed使用上的问题，欢迎加入speed框架群讨论和研究：5338343

发现一个bug
使用过程中，调用 list = query.getResults("select * from testexecute", new Object[] {}
, TestExecuteVO.class, pagin);
却返回null，这是因为jdk打包问题，请尝试下载新版本jar包。如果实在无法解决直接引入源码编译。
欢迎加入qq群：5338343 进行讨论。

昨天下了用了一下，感觉挺爽，不用配置，呵呵，避免因为配置而带来的错误，好，总比hibernate那么多配置文件方便，启动时候慢得要命，上个项目就是用hib，用oracle数据库，百万级数据量，项目我是中途进去，搞什么hib，靠，以前我也用过，没什么好感觉，应用经常要改表，配置烦的要死，简直增加工作量，同组的几个以前比较少接触hib，错了不知道往哪里找，项目出来后，客户投诉慢得要命，查询根本没法优化，没办法只能重新构了一个jdbc通用底层调用，问题解决了，而且部署到服务器也烦的要死，hib的意念有他的长处，但动不动就hib，也未免太过盲从，我觉得这个框架介乎hib和ibatis之间，期待它得功能完善，毕竟是国货，继续支持，最好能形成持久层的三国鼎立，呵呵（期待中.........）,我以后的项目都会继续用这个框架，希望项目能继续发展下去，替代hib，不，只是我们有多一种选择，一句话， 简单就好。

昨天下了用了一下，感觉挺爽，不用配置，呵呵，避免因为配置而带来的错误，好，总比hibernate那么多配置文件方便，启动时候慢得要命，上个项目就是用hib，用oracle数据库，百万级数据量，项目我是中途进去，搞什么hib，靠，以前我也用过，没什么好感觉，应用经常要改表，配置烦的要死，简直增加工作量，同组的几个以前比较少接触hib，错了不知道往哪里找，项目出来后，客户投诉慢得要命，查询根本没法优化，没办法只能重新构了一个jdbc通用底层调用，问题解决了，而且部署到服务器也烦的要死，hib的意念有他的长处，但动不动就hib，也未免太过盲从，我觉得这个框架介乎hib和ibatis之间，期待它得功能完善，毕竟是国货，继续支持，最好能形成持久层的三国鼎立，呵呵（期待中.........）,我以后的项目都会继续用这个框架，希望项目能继续发展下去，替代hib，不，只是我们有多一种选择，一句话， 简单就好。

我试了一下，感觉很好，不用配置，查询语言是我最熟悉的SQL语言。
有点orm经验的人，看speed框架文档基本上就可以进行开发了，不像学hibernate要经过一个漫长的学习阶段。
我准备用speed框架写个cms系统，来测试一下speed框架的实用性。
严重支持国产。

看看了案例，不错，问一个问题，如下代码是保存，非常类似Hib，但是没有SQl语句，如何保证Article 和数据表的字段之间映射？比如，程序怎么知道article的xxxx字段和数据表的ppp字段实际是映射的？



 public void postArticle(Article at) throws Exception {
    Engine engine = null;
    try {
      engine = BaseEngine.getForumEngine();
      engine.save(at);
      engine.commit();
    }
    catch (Exception ex) {
      engine.rollback();
      throw ex;
    }
    finally {
      engine.closeEngine();
    }
  }

> 看看了案例，不错，问一个问题，如下代码是保存，非常类似
> ib，但是没有SQl语句，如何保证Article
> 和数据表的字段之间映射？比如，程序怎么知道article的xxx
> 字段和数据表的ppp字段实际是映射的？
>
>
> 


> public void postArticle(Article at) throws Exception
> {
> Engine engine = null;
> try {
> engine = BaseEngine.getForumEngine();
> engine.save(at);
> engine.commit();
> }
> catch (Exception ex) {
> engine.rollback();
> throw ex;
> }
> finally {
> engine.closeEngine();
> }
> }


目前只实现了sql关联视图对象返回，至于关联级CRUD还没有实现，不过这已经比传统的持久层作的工作少多了。关联CRUD毕竟这只是一个初期的版本，目前先把基本JDBC的API完成，JTA事务完成。大概2.0版本会以一个全新的面貌给大家批示。希望得到大家的认同与支持。

还有对于CRUD语句是框架内部把SQL自动产生的。Article 是表名字，与javabean对象名字相同。Speed框架要求表、视图设计对象逻辑设计模式结合开发，视图就是需要显示在页面上面的javabean，该javabean的名字与表名字可以不同，但属性必须与查询出来的集合属性对应。也就是如下：

engine = EngineFactory.getEngine("link2");
Query query = engine.getQuery();
list = query.getResults("select b.money1 as money from testexecute a ,test b where a.id=b.id", new Object[] {}, TestExecuteVO.class, pagin);

public class TestExecuteVO extends TestExecute{
public TestExecuteVO() {
}
private Integer money;
...
}

up

我现在的项目也是这样做的，基本思想和你类似，只需要用工具根据数据库生成Bean就可以了，bean和数据库表及表的字段一一对应。 在增删改查时用反射取得bean对应的表，字段等拼成sql语句。对简单的增删改提供了统一方法，程序员直接调用即可基本不用再写sql语句，复杂的查询语句还是要自己写。 查询语句的结果封装成POJO,或者动态bean.

优点是上手快，开发速度快，缺点是现在还没有处理对象之间的关系。

下页