冷静的比较一下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君继续,作为一个先行者的勇气,望你能做出一个优秀的框架!

评论

106 楼 qfstudying 2011-07-06  

永远不要吝啬你的鼓励，一句鼓励的话可能会成就一个人，或者成就一个伟大的开源项目:)；光说别人的不好，不如给别人一些建设性的意见；如果不能给建设性的意见，或许我们没有资格去.......

105 楼 qfstudying 2011-07-06  

永远吝啬你的鼓励，一句鼓励的话可能会成就一个人，或者成就一个伟大的开源项目:)；光说别人的不好，不如给别人一些建设性的意见；如果不能给建设性的意见，或许我们没有资格去.......

104 楼 evanz 2010-10-09  

抄来抄去，不如直接jruby用rails

103 楼 LXJ_hmxc 2010-10-09  

dennis_zane 写道

xly_971223 写道

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

也不能这样说，是我最后给的良好，因为有些疑问也是我的疑问，希望douyu作者来解答的。但是后面的人身攻击已经偏离讨论的本意，我实在不明白为什么一定要带着偏见看douyu，douyu本身是有创新的，需要肯定，就看后面怎么发展。

   

102 楼 鱼言风语 2010-07-18  

回归正题，一个局外人看这个帖子，对于楼主和caoyangx的发言的感觉就2个字：

矫情！

101 楼 鱼言风语 2010-07-18  

smiletuna 写道

那个啥 play..我听都没听过..java的框架 真的比应用多...

这个回复是亮点！

100 楼 seth_yang 2010-07-15  

solonote 写道

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

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

个人愚见，动态编译除了不重启服务器外，还能做很多事情。比如额外代码生成、比如内置规则应用、甚至注释性规则应用等等。
甚至，在某种程度上，高级模板技术都可能使用动态编译。（当然，以上所提到那些特性也可以通过其他方式/技术，如反射，如字节码修改等等来实现，但我个人还是认为动态编译有时能够做的更好，毕竟编译器对源码的理解是最深刻的）。

再者，动态编译也是一种技术。个人认为技术仅仅是工具，用于解决问题的工具，什么工具你使用的顺手就用什么工具，当前场合下适合使用什么工具就用什么工具，没什么好炫耀的，也没什么好值得炫耀的，难道斧子就一定比锤子更好吗？

以上纯属个人观点，无心得罪，若有冒犯，敬请谅解。

99 楼 sarstime 2010-04-22  

<div class="quote_title">stray 写道</div>
<div class="quote_div">
<div class="quote_title">helian 写道</div>
<div class="quote_div">
<br><br>中国怨气比较大，讨论个技术动不动就战。</div>
<p><br><br>这位老兄明白人，现在的人怨气太大了，不就是一场普通的技术争论嘛，何必动不动投隐藏。javaeye的牛人们难道不知道真理越变越明么？然道所有的伟大技术都是某个牛人憋在娘胎里就能想好的么？不是的，所有的伟大东西都是经过广泛争议而产生的，你动不动就投了隐藏，这不是抽调了讨论的平台嘛，这个我们的天朝动不动屏蔽你的网有什么区别呢。强烈鄙视那些没事投隐藏的家伙。<br><br><br>        <span style="background-color: #ff0000; font-size: small;"><strong>我不同意你的观点，但是我誓死捍卫你说话的权利。</strong></span></p>
<p> </p>
</div>
<p>坚决同意红框里面的话</p>

98 楼 solonote 2010-04-21  

xchpanda 写道

我看Play的文档说是，不是用的servlet规范，想问问LZ，它war部署方式的性能怎么样，并发啊稳定性啊什么的测试效果怎么样？

Play 还是用的J2ee标准，只是自己封装了一层，适配器模式。参见
http://www.iteye.com/topic/539636

97 楼 Arden 2010-03-27  

现在又有了一个scotterframework框架，http://www.scotterframework.org

96 楼 xchpanda 2010-03-26  

我看Play的文档说是，不是用的servlet规范，想问问LZ，它war部署方式的性能怎么样，并发啊稳定性啊什么的测试效果怎么样？

95 楼 flyinglife 2010-03-26  

斗鱼作者，我坚挺你，就嚣张怎么了？你看看牛顿多嚣张，没事，我始终认识只要坚持做你认为正确的事就行了！！！

94 楼 yangfuchao418 2010-03-14  

中国”牛人“，都是这种心态，先根本没有认真仔细对比两个东西，仅仅凭着多一方的多了解就否定其他人的，往往要给别人指出许多错误，还得意洋洋的，认为多么的牛。

93 楼 thinkforever 2010-01-27  

引用

第一，讨论技术就要讨论得澈底，技术不是哲学

你说白的好看，我说黑的好看，怎么讨论彻底？大家都可以保留自己的意见，这么激动干嘛。

92 楼 bonny 2010-01-19  

play现在真的非常非常好用。

91 楼 jbon 2010-01-19  

从ZHH的隐藏贴的开头看，ZHH是要说明他的实力问题，不是对比两个框架。

每人怀疑你的能力，楼主的文字里也没有任何藐视你的能力的言语，只是在对比框架的优劣而已。

90 楼 Arden 2009-12-24  

1）play!的routes，有一个问题就是/test/home,/test/home这样的访问，后面多一个“/”的问题，如果想不管有没有“/”都能访问就必须得设置两次。我觉得这一点很不方便。

2）如何支持多个数据源？

89 楼 avaj 2009-12-05  

怎么有点c#好还是java好的味道了？

play!的routes非常的方便，利用它我可以使用Rest式的url，对搜索引擎非常的友好。有一个全局的配置文件，有什么不好的？


本来就是说的两个层次的事情。我觉着downpour说的是有道理的。

----
我觉着你们的争论是两个层次的，根本不对路，所以谁也说服不了谁。

举个不太恰当的例子：

甲跟乙说：你的系统太垃圾了，不好。

乙问：为什么？

甲说：我们的系统使用了最新的技术，可以说是当今最牛B的技术。而你们还是用20年前的老技术。

乙说：虽然我们使用的是20年前的老技术，但是我们的客户对我们的系统非常的满意，稳定，高效，易于维护....

甲乙完全是从两个出发点评价一个系统...

对于框架来说，其中之一的用户就是程序员。我也是个程序员，我不会去关心你的技术多么牛B，我只关心我要用的框架是不是一个很有生产力的东西，是不是一个稳定高效的东西，能不能满足我的要求。

我认同Restful式的架构风格，而play的routes非常的简单实用，没有什么麻烦的，在项目开发的时候不会给我带来任何的不便(最起码现在是)，能够让我不需要实用url重写就能快速优质的获得Rest式的url....有什么不好的呢？至于play!如何实现的？技术是不是先进牛B，这是次要的。

这本身就是萝卜青菜的问题，而不是一个技术问题，不是谁的框架的技术含量更高的问题。也不是谁好谁坏的问题。

88 楼 murainwood 2009-12-05  

firebody 写道

一个产品出来，需要经过好几个阶段： 构思-》设计-》初步实现-》雏形--》初级版本--》投入试用--》反馈-》改进--》更高级版本--》推广


而所谓革命性的产品，那就更需要一个厚积薄发的过程。

相比最近闹得轰轰烈烈的两个产品： play Framework  还有 douyu。 

才开始到 “雏形” ，就开始大张旗鼓的宣传 。 既然是雏形，那就肯定会有很多问题，你现在一拿出来，自然有吹捧之风，但在资深人员看来不免有这个感慨： “浮躁啊。。。。” 


所以，我建议这两个框架的作者，你们继续努力完善，不断在实际项目中得到经验来完善，然后慢慢形成一个自己的圈子。 这样一个推广过程我认为是很好的。

让我想起了当年的Jdon....呵呵

87 楼 guolimin19821118 2009-12-05  

ZHH2009 写道

downpour 写道

你的自信心已经膨胀到一定的境界了，所以我们没有讨论下去的必要了。

我已经很清楚的指出，你列出的有关控制器层的比较层次，我认为都站不住脚。这是一个哲学问题，你认为是正确的，可我认为不正确。所以我认为你随便就这样的问题下结论是不合适的。

routes好，不光是我一个人的观点，这是包括我在内的许多开发者共同的观点。站在一个项目的角度，无论从编程还是调试，它的优势都非常明显。我并没有强迫你接受routes，你也不能强迫我说routes不好吧。

从你的言语态度来看，你对你自己所谓的创意已经自豪到自满的地步。大家都是开源项目的作者，虚心接受别人的意见，承认自己的不足，或许对你的项目更有利。就你在你的帖子中发表的有关View层的3种解决方案，以及对美工和程序员之间关系的表述中来看，我认为你的经验还不足以让人信服。

不再对你的东西发表评论。希望你好自为之，因为你的fans会来吹捧你，给你投精华帖来满足你的自信心。我希望这种自信心不会成为一种虚荣心。

第一，讨论技术就要讨论得澈底，技术不是哲学，
我说某一个技术实现得不好，我能给出代码，能讲清它哪里实现得不够好，
如果你跟我讨论的是同一个技术问题，你说它好，那么你起码也要给出例子来说明它真的好，
而不能把哲学问题牵扯进去，不能总是想当然，真理并不总是掌握在大多数人手中的，
作为开源项目的作者更应该要有严谨的治学态度。

第二，我从来都不认为我有什么了不起，就连发个帖我都在时刻掂量着是否有可能被隐藏。

第三, 只要别人说得好，像rich、Laynepeng还有其他人(所有这些人我都不认识)的意见我都有认真思考，
就像上次rich提的那些意见(比如是否可以考虑兼容JSP/Servlet容器)我都已采纳了。

第四，近期不会再来JavaEye发主题帖，直到Douyu正式发布。

第五，我在JavaEye注册过几个帐号，每年来JavaEye发帖都用新帐号，我从来不在乎什么星星钻石。

第六，也希望你也好自为之，即使你不说是你投我的隐藏帖，我也知道有你一份，
我在JavaEye泡了至少5年了，我了解你是什么样的人，不要总是一副高高在上的样子，
多多关心、鼓励一下新人。

海纳百川 有容乃大
斗鱼作者有点过了
做好自己才是最重要的
不要在争吵了！在争就 没有意思了