俺在用hibernate的时候由于封装的没有经验经常出现线程问题,后来用spring的hib模板才搞定,真是累人啊,2边都要配N多,郁闷那~

看到这个框架觉得我终于看到了想要的 DD!!请问这里的操作线程安全吗?我一定抽时间测一下。

还有,我看例子里都要finaly,能不能用AOP解决一下呢?期待ing!!

aop做这个太麻烦,一个回调模式就搞定了

看介绍和大家的讨论知道正是我想要的,嫌HIBERNET太庞大繁杂,学习成本高,特别对于写惯了SQL的程序员来说,speed可能比较适合,打算自己先用speed做个小项目试试。

是么?谢谢大家支持Speed框架,beta4版本已经发布了,大伙可以下载。beta4修正了oracle的bug。

希望banq兄能为国内开源项目贡献一下,做一个Speed框架和jdon框架结合做的例子,让喜欢的人能做个项目开发的参考。

支持国产

》希望banq兄能为国内开源项目贡献一下,做一个Speed框架和jdon框架结合做的例子

两个组合在一起是自然组合,非常简单,如果看懂JdonFramework和Hibernate组合案例,就应该学会JF+Speed案例。

这个东东一定是个新手弄的东东。不值得一提。还够不成“框架”的条件,我觉得应该说是组件或许比较适合。

> 这个东东一定是个新手弄的东东。不值得一提。还够不成“框
> 堋钡奶跫揖醯糜Ω盟凳亲榧蛐肀冉鲜屎稀?

既然你看不起这个东东,那你一定是一个高手,那你搞个框架出来,给大家学习一下,强烈要求...........

我也认为,只能算组件而已。实际上再进一步发展下去,几乎肯定又是走hibernate的路子,除非lz有崭新的思路,否则无法又是一个重复的低劣的轮子。

> 我也认为,只能算组件而已。实际上再进一步发展下去,几乎
> 隙ㄓ质亲hibernate的路子,除非lz有崭新的思路,否则无法
> 质且桓鲋馗吹牡土拥穆肿印?
这位朋友有没有亲身用过这个持久层框架?没用过你怎么知道它低劣?
至于轮子,呵呵,轮子也有不同型号,不同的轮子适合不同的汽车,框架
是,不同框架适合不同的项目开发需要,而且这个框架和hibernate的设计
出发点也不同,一个是表对象,一个是表视图,这个框架是减少增删改操作
利用sql的优化实现不同数据库查询,我个人不否认hibernate有它设计上的
优点,但是在开发应用上用哪种框架合适,有开发经验的朋友应该有所体会,
每种框架都有优缺点,我们只挑合适的,难道多一种选择会有问题?除非不同的
汽车都用一种型号的轮子

互相吹捧毫无意义,尤其是搞技术的,技术自己会帮你吹的。
我并无贬低这个的意思,只说它只能算组件而已。假如它确实包含了很多创新的地方,我也肯定会帮你吹。
源代码都评估看过几遍了,还用得着来试用开发么?
“减少增删改操作”是每个项目经理都会设法实现的一个组件,并不是什么了不起的事情。
假如这个框架要实现hibernate的类似ORM操作,要完成的工作或设计几乎肯定会hibernate类似,sorry,hibernate走在了你前面。也许你是天生的程序家,好,请给出这个框架的下一步发展计划和实现方案。不要给我空洞的唱高调,毫无意义,不要学那个EasyJF的所谓大虾同志。
不过要说的是,这个框架用来开发一些小规模的无复杂数据表关系的应用还是不错的。

我来说句,实际上我们以及使用SPEED持久层框架在电信系统上,并且是一年前的事情了,当时是没有重构的代码。数据量最少也10W-100W级别多表关联,数据库是ORACEL。

如果您对Speed的发展有好的指导性的意见欢迎提出。这也是为了国内java作一分小贡献。

再往前跨一步就走上了hibernate的路线。这个组件当前的状态是“介绍一种免xml配置的持久层实现快速开发的框架”说法的最高状态了,再搞其它都是多余。顶多的改进范围不过是补充一些工具而已。

感谢这位仁兄对SPEED框架前景的描绘和预测,希望您能给点实际的贡献,我们会注意不要走上HIBERNATE的旧路。

SPEED框架的目标是敏捷与快速,对于工业化流水线企业开发非常有利,简单的说SPEED是针对大型企业系统需求变化非常快速的开发过程和降低程序员入门成本的框架。与HIBERNATE在应用层次上有着明显的区分。