//因为有一些需要的字段没有,比如每张表对应的javabean,某个字段是否在列表中显示,是否在查询中显示
你可以利用表、视图对象，表对象javabean针对的是表，视图对象javabean针对的是页面视图。而视图对象可以继承于表对象，那么修改起来非常方便，表加字段在表对象上加即可，视图对象若不是制定属性即不需加。
视图对象还是得保存到数据库或配置文件中,因为用户可能有这样一种需求,自定义在列表,查询,excel导入导出中需要的字段,自定义字段在表单中的显示位置等等.
> 视图对象还是得保存到数据库或配置文件中,因为用户可能有?> 样一种需求,自定义在列表,查询,excel导入导出中需要的字段
> 自定义字段在表单中的显示位置等等.
speed框架是这样处理你得用户自定义需求得。
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;
private Integer total;
...
}
sql:select b.money1 as money from testexecute a ,test b where a.id=b.id
sql只拿出money 没有拿出total，通过拼装sql得原则把值填充到视图javabean上面，而页面也就只需要把其选择得字段判断显示出来即可实现。
很迷茫。
期待阿bang作出专家级的评价。最好能把它跟jdoframeword比较下。
关注中。
呵呵，用了一下，其实东西不错，切实可以做speed开发，而且实现了
cache功能，我以前也做过类似的这种框架，但是随项目
规模的扩大和复杂度的提高，这样的框架就显的不够用了，
尤其从MDA和设计构架上来说，确实不够OO，在处理对象之间的关系的时候就没那么灵活了，这方面比起bqao的JDon框架差了!
不过还是支持，做的很好！
speed在oo方面确实需要提高改善，2.0版本以后应该得到很大的提高。1.0以前speed只支持单个对象映射，目前确实实现了speed的快速开发，并且使用到大型系统上。目前不支持配置性扩展，支持代码级别扩展，就目前应用需求来说，代码级别扩展已经可以基本满足需求，并且speed带来的效益是有目共睹的。
开发以时间成本为核心，如果框架不满足以上需要那使用框架是没有意义了。希望大家支持和理解speed，同时给予speed提升的时间与建议，希望speed能带来更多的成功项目。谢谢支持。
有没有使用技术文档啊,删除和修改操作条件如何加上去?
> 有没有使用技术文档啊,删除和修改操作条件如何加上去?
目前只有例子，技术文档需要时间和人手制作。请耐心等待，若有疑问请加Q群：5338343
项目进行期间人员流动性也会比较大，这样的框架不但可以降低开发门槛，节约开发时间，解放程序员开发难度，而将精力集中在业务逻辑上，我不知道简单有什么不好，难道每天对者一大对文档参照和配置文件开发是好事？
降低成本是框架的最终目的。框架不是让开发者拿出来炫耀的，而是能够实实在在的降低公司的成本！！
> 项目进行期间人员流动性也会比较大，这样的框架不但可?> 降低开发门槛，节约开发时间，解放程序员开发难度，而将精
> 性谝滴衤呒希也恢兰虻ビ惺裁床缓茫训烂刻於哉
> 一大对文档参照和配置文件开发是好事？
>
> 降低成本是框架的最终目的。框架不是让开发者拿出来炫?> 的，而是能够实实在在的降低公司的成本！！
我们实际使用Speed框架确确实实降低了入门门槛，和减轻了开发强度和缩短了时间。
至于你是否认同这个观点，可以进行小步尝试。
希望大家不要认为开源或者提供免费使用的框架是作者拿来炫耀的。开源目的是为了大家能认识真正的开发是实际的，不是夸夸其谈和根风，技术是人创造的，并且每个人都可以创造。好东西大家分享，不愿意可以不用不试。
我这两天用speed做了几个测试例子，感觉还不错。分页查询都挺快的（数据量为18万条记录）。我认为：大部分应用软件都可以用speed开发，比较适合真正写代码的程序员啦，比较合适我们（个人）目前的开发模式，如果能继续完善功能就更不错啦。希望大家同心协力推出我们中国人自己的开发平台哦，而且是开源的。。。
>这方面比起bqao的JDon框架差了!
Jdon框架主要是业务层框架，可以和Speed这样的持久层框架合并一起应用，JiveJdon3本身就使用JDBC持久层。
我个人目前认为，持久层不必太注重对象化，因为按照DDD理论，我们可以在业务层和持久层的衔接处，做一个对象模型的工厂，也就是自己实现数据和对象的转换和封装。
持久层关键是要方便学习，象Hibernate那样一步到位衔接领域模型，对很多人来说还是太超前了，需要一个过渡，否则思维难以转变，Speed的价值我认为在于此。
你好呀！
我感觉这个框架不错呀！可是我没有了解过！可以我一个例子嘛！我好想去体现一下！多谢！！
我的有心邮箱：cdz_0605@163.com
谢谢banq，谢谢各位。我们一定会把Speed搞好。大家多多给点意见。
研究了一下speedframeWork ，个人认为，在添加与获取，还是不如hibernate +spring 来得方便，不过它省了配置的过程，但加大了DAO实现的复杂度，不知道从性能上考虑是否会比hibernate+spring来得更有优势还有待考证。