冷静的比较一下Douyu和Play Framework

刚刚用Play Framework做了一个小型项目,开发速度非常快.运行的速度也很不错,很稳定.
今天又看到了有同学开发了一个Douyu平台,下面评论一大堆,非常火爆,冷静下来再看一遍帖子,
没发现Douyu能在开发速度上比Play做的更好.

斗鱼作者ZHH:

引用

Play!框架除去与Douyu共有的动态编译之外，在我看来并没有多少值得我借鉴的思想。
我说Play!框架更像是个胶水框架也是有根据的:

我的分析:

1.动态编译
动态编译除了在开发模式下能够修改java文件而不重启服务器以外还有其他用处吗?(非常希望ZHH或者其他大侠能给我答案.)
从这一点出发,我不关心Play和Douyu的动态编译技术谁牛逼.
我认为Play在动态编译上已经做的很好,无论你修改Entity,Controller或者view,都无需重启服务器.

臆测:ZHH一直强调动态编译,我认为一部分原因是动态编译所用的技术比较深,值得炫耀.

2.ORM
Douyu:从数据库生成Entity
Play:遵循JPA标准,根据Entity生成表
这里我不想扯淡谈是否遵循标准的问题.我只想说,JPA模式相比较Douyu有以下优势:
a.Play可以在开发模式时用一个内存数据库,而Douyu必须你先安装一个数据库.在做原型程序的时候,这是很恶心的一件事情.
b.从数据库生成Entity与从Entity生成表在简单情况下是具有相同效率的,但是有以下需求时,明显的JPA要优于Douyu的ORM
b.1.Entity中有一些属性和方法不依赖数据库.这种情况从数据库生成Entity就很麻烦,生成了以后要手动去添加这些不依赖数据库的东西.
b.2.从数据库生成表依赖于特定的数据库,如果我换一个数据我必须要重新建表.

ORM上Douyu的方式完全败给JPA.

3.控制器
Douyu渲染一个试图参数是:

context.out("WhatTime.html", paramMap);

而Play的参数是:

render(param1,param2...);

Play的优势:
a.play不需要指明去渲染哪一个html,它根据方法名,Controller类去判定,Play定义的是一个规则.这种类似的规则在Play中还有很多,而且Play有一个特点,如果你不需要这种规则时,你往往可以去自定义.
而Douyu使用的方式是只能自定义.
b.play传给页面的参数不需要组织成一个map,更加自然.

4.视图
Play的页面模版有一套非常简单易用的tag机制,复用view非常的方便.Douyu当前的版本介绍里并没有提到如何复用view.

5.REST
因为ZHH没有实践过Play,其实Play的REST用一些pattern后会很简单的.
Play的REST做的是非常方便而且简单的,而Douyu没有这个功能.
在Play中REST只是作为route功能的一个子集,route功能还可以做其他的用处.

6.Testing
Play可以非常方便的做Unit Test以及FunctionalTest.
Play在Test上下了很多功夫,这一点大家实践一下就可以知道.
Play可以方便的组织测试数据,而这些数据是一个文本结构,不依赖于特定数据库.
也就是说即使你用的是一个内存数据库,你也可以很方便的组织测试数据.

7.关于第三方类库依赖以及大小
Douyu依赖的开源库很少,Play依赖了很多开源库,比如Hibernate等等.Douyu很小,Play下载下来需要90mb(其中还包含了python的解释器).
但我认为,作为一个非桌面应用程序来说大小和第三方类库的依赖完全不是评价一个framework的关键.

8.J2ee体系的支持
Play的应用程序发布以后会打包成一个war包,值得一提的是这个war包还是可以轻松的修改代码的.而且基本的程序结构也没发生什么变化.Play的war包可以运行在标准的J2ee容器中.
Douyu不支持原来的J2ee体系,只能运行在自己的服务器中.我不谈Douyu服务器和其他J2ee服务器的优劣.但是有一点
当前没有Douyu的Hosting提供商,你想用Douyu必须自己有一个服务器.而开发一个Play网站,仅仅租用一个tomcat空间就可以发布.
这会让Douyu陷入无人使用的境地,如果陷入这种境地,那么它就全无价值了.

9.其他的一些支持
Play对GAE也有支持,它还有很多的功能,比如Play的在运行出错时的报告非常的直观,你可以自己去了解和实践.

Play的"缺陷和问题":
Play有很多的静态方法,在Controller和Model中都有,静态方法带来的最大麻烦就是难以继承,这是很恶心的一件事情,这一点可能是Play框架的一个硬伤,不知道以后会不会有更正.

我用Play的感触是,这个框架是非常有经验的Web开发者所做的,非常的简单和方便,而且这个框架不像其他框架,当你进行真实开发时你会遇到很多难以达成的问题.就我的实践来说Play是非常易用和扩展的.

对于Douyu和Play,我的评价是Play是一个真正可以开发,而且我用过最方便的Java Web框架.我不知道用Play开发大型应用会不会遇到问题,这一点希望有实践经验的朋友来补充.
而Douyu就从当前发布的版本来说,除了它没有用静态方法以外,我看不到任何比Play有用的地方.

希望ZHH君继续,作为一个先行者的勇气,望你能做出一个优秀的框架!

评论

26 楼 xly_971223 2009-12-02  

很明显楼主是带着有色眼镜来评论play和douyu的
通篇只说play的优点和douyu的缺点

25 楼 zdmcjm 2009-12-02  

天下将大任于框架也,必先劳其筋骨,饿其体肤，空乏其身，行拂乱其所为。

24 楼 guazi 2009-12-02  

楼主的目的值得商榷一下，我支持douyu的作者。十分同意一下观点，

SeanHe 写道

不说什么，先支持一下douyu的作者，作为刚诞生的框架douyu还有很多东西要做，但是没有人能断言douyu就只是个玩具。国人最缺的就是创新精神，而ZHH2009却迈出了一步，至少向我这样的很多人还徘徊在老的老套路上

23 楼 超级潜水员 2009-12-02  

太崇拜douyu了,作者太强了,希望好好发展.

22 楼 helian 2009-12-02  

国人啊，动不动就战。。。怨念啊

期待斗鱼作者的比较帖

21 楼 tangbo530 2009-12-01  

支持DOUYU的作者，，，
确实不错。。。
希望能看到更好的东东

20 楼 pipilu 2009-12-01  

楼主写的挺好。支持一下。

19 楼 zxc005 2009-12-01  

solonote 写道

冷静的比较一下Douyu和Play Framework……
……
臆测:ZHH一直强调动态编译,我认为一部分原因是动态编译所用的技术比较深,值得炫耀.

臆测:solonote强调自身的冷静，我认为这句话基本上能体现solonote的冷静，但冷静的背后却是蔑视，而蔑视的背后则是妒忌。

18 楼 solonote 2009-12-01  

madbluesky 写道

别忙着打压..能给建议的真诚的给点建议,给不了建议的鼓励下也好啊..
拿一个成熟的框架与一个 0.1版本的东西比较本来就不公平.

请问你什么叫做“真诚的给点建议？”，在后面跟帖说“很好很强大”“支持国产”这种叫做建议？
我想只要是一个做技术的，自己会去实践的人都能看的此文的用意，我想Douyu的作者也能看懂。

17 楼 madbluesky 2009-12-01  

别忙着打压..能给建议的真诚的给点建议,给不了建议的鼓励下也好啊..
拿一个成熟的框架与一个 0.1版本的东西比较本来就不公平.

16 楼 hhh041 2009-12-01  

helian 写道

楼主，这有啥好比较的。。。

我也是这么想的

15 楼 joeyhacker 2009-12-01  

caoyangx 写道

leon1509 写道

恰巧前两天刚看了一下douyu，我记得作者也是建议不要使用douyu做商业项目吧？

一个作品只是用来玩玩的，而扯到正题上，却避而不谈，那么没什么好说的，谁胜谁败每个人心里自然有数。
虽然只是起步阶段，但是很多框架的先天不足，注定它的命运会夭折，虽然大家嘴上都说一些鼓励和支持的话，其实你们谁敢用？谁敢把它用到项目中？
框架这东西，就是为了解决某些问题而产生的，只有行和不行，没有还行这个选择，都是输不起的项目，都是负不起的责任，谁敢用这还行的东西来做项目，谁敢把自己的命运寄托在一个评价还行或以后会行的框架上？

说的有点过了~

14 楼 SeanHe 2009-12-01  

不说什么，先支持一下douyu的作者，作为刚诞生的框架douyu还有很多东西要做，但是没有人能断言douyu就只是个玩具。国人最缺的就是创新精神，而ZHH2009却迈出了一步，至少向我这样的很多人还徘徊在老的老套路上

13 楼 ZHH2009 2009-12-01  

caoyangx 写道

leon1509 写道

恰巧前两天刚看了一下douyu，我记得作者也是建议不要使用douyu做商业项目吧？

一个作品只是用来玩玩的，而扯到正题上，却避而不谈，那么没什么好说的，谁胜谁败每个人心里自然有数。
虽然只是起步阶段，但是很多框架的先天不足，注定它的命运会夭折，虽然大家嘴上都说一些鼓励和支持的话，其实你们谁敢用？谁敢把它用到项目中？
框架这东西，就是为了解决某些问题而产生的，只有行和不行，没有还行这个选择，都是输不起的项目，都是负不起的责任，谁敢用这还行的东西来做项目，谁敢把自己的命运寄托在一个评价还行或以后会行的框架上？

我不知道caoyangx为什么对Douyu有那么多成见(已经不只一次了)，当然我是不指望你去用的。
你想要跟我谈什么，要谈技术细节我非常乐意，就怕你不堪一击。

不了解我时，千万别随意像下面这家伙那样在Douyu的新闻中评判我:

ops2000 写道

不用说都能想到作者是一个没有经过正规计算机原理系统学习过的勤奋的编码人员，并且没有做过大型系统，顶多开发过网站的技术人员。

如果别人骂我是垃圾、SB之类的我肯定不会理睬(我才没这个闲情)，
但是请千万不要随便侮辱我的专业水准，除非我技不如人，我甘受羞辱，我会知耻后勇。


这个帖子我会回复，还会专门开一个新帖认真回复(同时比对Douyu与Play的差异)，
我从来不当逃兵。

12 楼 cloud21 2009-12-01  

caoyangx 写道

leon1509 写道

恰巧前两天刚看了一下douyu，我记得作者也是建议不要使用douyu做商业项目吧？

一个作品只是用来玩玩的，而扯到正题上，却避而不谈，那么没什么好说的，谁胜谁败每个人心里自然有数。
虽然只是起步阶段，但是很多框架的先天不足，注定它的命运会夭折，虽然大家嘴上都说一些鼓励和支持的话，其实你们谁敢用？谁敢把它用到项目中？
框架这东西，就是为了解决某些问题而产生的，只有行和不行，没有还行这个选择，都是输不起的项目，都是负不起的责任，谁敢用这还行的东西来做项目，谁敢把自己的命运寄托在一个评价还行或以后会行的框架上？

正解。

11 楼 caoyangx 2009-12-01  

leon1509 写道

恰巧前两天刚看了一下douyu，我记得作者也是建议不要使用douyu做商业项目吧？

一个作品只是用来玩玩的，而扯到正题上，却避而不谈，那么没什么好说的，谁胜谁败每个人心里自然有数。
虽然只是起步阶段，但是很多框架的先天不足，注定它的命运会夭折，虽然大家嘴上都说一些鼓励和支持的话，其实你们谁敢用？谁敢把它用到项目中？
框架这东西，就是为了解决某些问题而产生的，只有行和不行，没有还行这个选择，都是输不起的项目，都是负不起的责任，谁敢用这还行的东西来做项目，谁敢把自己的命运寄托在一个评价还行或以后会行的框架上？

10 楼 leon1509 2009-12-01  

恰巧前两天刚看了一下douyu，我记得作者也是建议不要使用douyu做商业项目吧？

9 楼 solonote 2009-12-01  

hetylei 写道

3.控制器

引用

a.play不需要指明去渲染哪一个html,它根据方法名,Controller类去判定,Play定义的是一个规则.这种类似的规则在Play中还有很多,而且Play有一个特点,如果你不需要这种规则时,你往往可以去自定义.
而Douyu使用的方式是只能自定义.

douyu实现这个应该很容易，毕竟Controller都是动态找的。

引用

b.play传给页面的参数不需要组织成一个map,更加自然.

douyu也不需要见例子。

4.视图

引用

Play的页面模版有一套非常简单易用的tag机制,复用view非常的方便.Douyu当前的版本介绍里并没有提到如何复用view.

douyu的视图作者说还需要整合，照现在的controller来看，整合freemarker之类是非常容易的

第一个问题,目前Douyu没有实现,空话就不说了,这样说来什么都是容易实现的.
第二个问题,如果不组织成map,就需要一个专门的view对象,更麻烦
第三个问题,目前没有,理由同一

8 楼 solonote 2009-12-01  

cloud21 写道

douyu是很有特点的，在这里并没有提出来。我觉得，是不完整的。

你可以进行补充,大家一起讨论它的价值
此贴只是想客观的比较一下Douyu和Play,也希望ZHH能获得一些有用的信息.

7 楼 hetylei 2009-12-01  

3.控制器

引用

a.play不需要指明去渲染哪一个html,它根据方法名,Controller类去判定,Play定义的是一个规则.这种类似的规则在Play中还有很多,而且Play有一个特点,如果你不需要这种规则时,你往往可以去自定义.
而Douyu使用的方式是只能自定义.

douyu实现这个应该很容易，毕竟Controller都是动态找的。

引用

b.play传给页面的参数不需要组织成一个map,更加自然.

douyu也不需要见例子。

4.视图

引用

Play的页面模版有一套非常简单易用的tag机制,复用view非常的方便.Douyu当前的版本介绍里并没有提到如何复用view.

douyu的视图作者说还需要整合，照现在的controller来看，整合freemarker之类是非常容易的