论坛首页 Java企业应用论坛

Without SSH/JSP/Servlet,不走寻常路,Java可以更酷

浏览 212081 次
该帖已经被评为精华帖
作者 正文
   发表时间:2009-11-17  
Douyu 服务器,可以完全替代SSH/JSP/Servlet 吗
0 请登录后投票
   发表时间:2009-11-17   最后修改:2009-11-17
helian 写道
ZHH2009 写道

我不了解grails,不过说来有趣,
Douyu的ORM最初就是用grails这种先有模型类,再根据模型类生成表的,
但是后来我把这种方案舍弃了,
原因很简单,编译器能分析开发人员手写的模型类的任何格式,
但是却不能自由控制数据库,因为每个数据库都是不一样的,都有自己的专有特性。
除非你自己再为每个数据库都实现一个你自己的JDBC驱动程序,
否则自动生成的SQL语句对于DBA来说很难让他满意的,
还不如反过来,先有表再有模型类,这也是JDBC的强项,同时还减轻了编译器的负担。


不同数据库的问题我想hibernate处理的还可以。Grails也就是利用了hibernate的功能。
douyu的这种ORM方式目前看起来是贫血模型,是不是用户自己要外面再包一层把逻辑放进去?



目前Douyu的ORM在处理JDBC规范中的高级数据类型(Advanced Data Types)方面并不是太好,
比如BLOB, CLOB, ARRAY, REF, STRUCT, XML, and DISTINCT这些,
java.sql.Connection接中在JDK1.6引入了createBlob()、createClob()等等这些处理高级数据类型
的通用方法,但是JDK1.6还是太新了,有些JDBC驱动都不支持这些方法,
所以为了更大的通用性,也必须采用方言机制来处理这些问题。

还有在字段值合法性自动校验这方面也做得不好,在多表查询时也不是很好(要强制类型转换)。

这三个方面会是接下来的改进重点。

其他方面我个人还是挺满意的。



Douyu的这种ORM方式目前就是贫血模型,不用再加什么逻辑层,
Douyu的com.douyu.main.Context就相当于Hibernate的org.hibernate.Session,
我起初对比了Rails的ActiveRecord与Hibernate,
觉得Hibernate的方式在处理多数据库事务时比较方便,
而Rails的ActiveRecord把模型类的crud都内置了,
还是必须手写模型类,我也详细看了那本"应用Rails进行..."中的14、15章,
反正里面讲Rails在处理多数据库事务方面不强,
最后还是舍弃了Rails的ActiveRecord那样的充血模型。

Douyu的多数据库事务处理可以在多个方法调用中来回穿梭,
只要引用的都是同一个com.douyu.main.Context就行了。

呵呵,不过,其实Douyu的ORM可以自由在贫血模型和充血模型中自由切换的
(只要模型类 extends SqlBase就是充血模型,但是SqlBase没有对开发人员开放)
只是我个人的偏好,强制推荐贫血模型罢了,也没在配置文件中加有开关。
0 请登录后投票
   发表时间:2009-11-17  
ZHH2009 写道
helian 写道
ZHH2009 写道

我不了解grails,不过说来有趣,
Douyu的ORM最初就是用grails这种先有模型类,再根据模型类生成表的,
但是后来我把这种方案舍弃了,
原因很简单,编译器能分析开发人员手写的模型类的任何格式,
但是却不能自由控制数据库,因为每个数据库都是不一样的,都有自己的专有特性。
除非你自己再为每个数据库都实现一个你自己的JDBC驱动程序,
否则自动生成的SQL语句对于DBA来说很难让他满意的,
还不如反过来,先有表再有模型类,这也是JDBC的强项,同时还减轻了编译器的负担。


不同数据库的问题我想hibernate处理的还可以。Grails也就是利用了hibernate的功能。
douyu的这种ORM方式目前看起来是贫血模型,是不是用户自己要外面再包一层把逻辑放进去?



目前Douyu的ORM在处理JDBC规范中的高级数据类型(Advanced Data Types)方面并不是太好,
比如BLOB, CLOB, ARRAY, REF, STRUCT, XML, and DISTINCT这些,
java.sql.Connection接中在JDK1.6引入了createBlob()、createClob()等等这些处理高级数据类型
的通用方法,但是JDK1.6还是太新了,有些JDBC驱动都不支持这些方法,
所以为了更大的通用性,也必须采用方言机制来处理这些问题。

还有在字段值合法性自动校验这方面也做得不好,在多表查询时也不是很好(要强制类型转换)。

这三个方面会是接下来的改进重点。

其他方面我个人还是挺满意的。



Douyu的这种ORM方式目前就是贫血模型,不用再加什么逻辑层,
Douyu的com.douyu.main.Context就相当于Hibernate的org.hibernate.Session,
我起初对比了Rails的ActiveRecord与Hibernate,
觉得Hibernate的方式在处理多数据库事务时比较方便,
而Rails的ActiveRecord把模型类的crud都内置了,
还是必须手写模型类,我也详细看了那本"应用Rails进行..."中的14、15章,
反正里面讲Rails在处理多数据库事务方面不强,
最后还是舍弃了Rails的ActiveRecord那样的充血模型。

Douyu的多数据库事务处理可以在多个方法调用中来回穿梭,
只要引用的都是同一个com.douyu.main.Context就行了。

呵呵,不过,其实Douyu的ORM可以自由在贫血模型和充血模型中自由切换的
(只要模型类 extends SqlBase就是充血模型,但是SqlBase没有对开发人员开放)
只是我个人的偏好,强制推荐贫血模型罢了,也没在配置文件中加有开关。


将来还是多给用户些选择吧。我个人是无所谓。
0 请登录后投票
   发表时间:2009-11-17   最后修改:2009-11-17
robbin 写道
最近很忙,没有时间来得及仔细看斗鱼框架,不过很巧的是,前几天刚刚看过Play! Framework,和斗鱼框架思路都是一样的,抛弃了Servlet容器,完全自己另起炉灶,我非常赞赏这种思路。Servlet就是Java Web快速开发的罪恶之源,只有干掉Servlet,Java Web开发才有未来。过去这些年,Java干不过动态语言,很大程度上不是Java的错,而是Servlet的错。

现在还没有来得及仔细看这个框架,所以还提不出来什么建议,只说两点:

1、建议楼主关注一下Play! Framework,看看有没有可以取长补短的地方
2、尽早开源,可以发动社区的力量,一个人干,毕竟力量有限,很难有前途





1、今天看了大半天的Play! Framework, 
思路有点像,但有很多地方有差别,我会在这几天内写个文档说一下Play! Framework和Douyu有什么不同。

2、会开源,但近两个月内可能没那么快发布,还有一些工作要做的,没有文档,即使马上放出源代码也帮不上什么忙,
所以需要点时间。
0 请登录后投票
   发表时间:2009-11-17  
我最佩服的是楼主一直守着这贴,不停回复长达两天+
0 请登录后投票
   发表时间:2009-11-17  
前几天在新闻中看到这个东东,没仔细看就随便评论了一下,惭愧!
老实说,就凭楼主的执着,小弟已经佩服的五体投地了。
你会成功的!
0 请登录后投票
   发表时间:2009-11-17  
iaimstar 写道
我最佩服的是楼主一直守着这贴,不停回复长达两天+


因为这三天要给自己放假,回帖算是件很轻松的事了,
前30天每天写代码12小时以上有点累。

过了明天,就不会守着这贴了。
0 请登录后投票
   发表时间:2009-11-17   最后修改:2009-11-17
-楼主在读博吗???真羡慕能有自己支配的时间...

-似乎世界伟大的东西刚开始都是玩家文化.支持楼主这样玩下去..

-我觉得等楼主开源后,社区可以搞个基金什么的赞助下,打铁要趁热,望楼主早日开源.
0 请登录后投票
   发表时间:2009-11-17  
支持楼主!希望早日有实际的应用。有大公司也支持一把的话就好了。
0 请登录后投票
   发表时间:2009-11-17  
C_J 写道
楼主在读博吗???

真羡慕能有自己支配的时间...

我觉得要是来点实践点的,可以等楼主开源后,社区搞个基金什么赞助下..有钱出钱,有力出力,能搞点实质性的东西..



不是,我工作了四年后,然后觉得应该换换生活了,接着就过了4年这种自己支配时间的生活,
我有看过书想考研究生,但是报了三次名,每次都没考,现在还有这个余念,可能明年又想去报名。。。

其实我发这个帖的当下,是怀着"被隐藏"的心情发的,
平时不怎么上网交流,连MSN都没用过,顶多也是时不时来JavaEye看看10来分钟,

我只是个很普通的人,也请所有的朋友们不要把我抬得那么高,
这样会有压力。

0 请登录后投票
论坛首页 Java企业应用版

跳转论坛:
Global site tag (gtag.js) - Google Analytics