|
该帖已经被评为精华帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2009-11-17
Douyu 服务器，可以完全替代SSH/JSP/Servlet 吗
|
| 返回顶楼 | |
|
发表时间：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没有对开发人员开放) 只是我个人的偏好，强制推荐贫血模型罢了，也没在配置文件中加有开关。 |
| 返回顶楼 | |
|
发表时间：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没有对开发人员开放) 只是我个人的偏好，强制推荐贫血模型罢了，也没在配置文件中加有开关。 将来还是多给用户些选择吧。我个人是无所谓。 |
| 返回顶楼 | |
|
发表时间：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、会开源，但近两个月内可能没那么快发布，还有一些工作要做的，没有文档，即使马上放出源代码也帮不上什么忙， 所以需要点时间。 |
| 返回顶楼 | |
|
发表时间：2009-11-17
我最佩服的是楼主一直守着这贴，不停回复长达两天+
|
| 返回顶楼 | |
|
发表时间：2009-11-17
前几天在新闻中看到这个东东，没仔细看就随便评论了一下，惭愧！
老实说，就凭楼主的执着，小弟已经佩服的五体投地了。 你会成功的！ |
| 返回顶楼 | |
|
发表时间：2009-11-17
iaimstar 写道 我最佩服的是楼主一直守着这贴，不停回复长达两天+
因为这三天要给自己放假，回帖算是件很轻松的事了， 前30天每天写代码12小时以上有点累。 过了明天，就不会守着这贴了。 |
| 返回顶楼 | |
|
发表时间：2009-11-17
最后修改：2009-11-17
-楼主在读博吗???真羡慕能有自己支配的时间...
-似乎世界伟大的东西刚开始都是玩家文化.支持楼主这样玩下去.. -我觉得等楼主开源后,社区可以搞个基金什么的赞助下,打铁要趁热,望楼主早日开源. |
| 返回顶楼 | |
|
发表时间：2009-11-17
支持楼主！希望早日有实际的应用。有大公司也支持一把的话就好了。
|
| 返回顶楼 | |
|
发表时间：2009-11-17
C_J 写道 楼主在读博吗???
真羡慕能有自己支配的时间... 我觉得要是来点实践点的,可以等楼主开源后,社区搞个基金什么赞助下..有钱出钱,有力出力,能搞点实质性的东西.. 不是，我工作了四年后，然后觉得应该换换生活了，接着就过了4年这种自己支配时间的生活， 我有看过书想考研究生，但是报了三次名，每次都没考，现在还有这个余念，可能明年又想去报名。。。 其实我发这个帖的当下，是怀着"被隐藏"的心情发的， 平时不怎么上网交流，连MSN都没用过，顶多也是时不时来JavaEye看看10来分钟， 我只是个很普通的人，也请所有的朋友们不要把我抬得那么高， 这样会有压力。 
|
| 返回顶楼 | |
