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

评论

86 楼 carlkkx 2009-12-05  

引用

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

我觉得他的意思应该是更多从API的角度来看待这个问题，就是说API设计的好不好要更多从API的使用者评价来看。不过我倒是觉得你的这种模式不错，action的模式我觉得不错。

85 楼 ZHH2009 2009-12-05  

downpour 写道

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

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

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

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

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

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

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

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

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

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

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

84 楼 downpour 2009-12-05  

ZHH2009 写道

我说Play在应用层次方面比Douyu要高几个等级，
那是因为Play开发得早，功能比Douyu要多，比Douyu完善，所以Play能运用于生产环境，
但是并不代表在某一功能的技术实现策略上Play也比Douyu高，
比如在控制器层的动态编译和routes的问题上我都给了具体代码并详细对比了两者的技术实现策略。

你不能总是拿Douyu不是“成品”去判断技术实现策略的好坏，
也不能用你"为Struts2编写lighturl插件"的经验去判断，
因为Struts2或者lighturl插件跟Play和Douyu完全是两种不同的东西，没有可比性。

你说的实践问题，有没有在生产环境中打磨的问题是应用层次的问题，
这跟判断一种技术实现策略的优劣并不存在直接的关系，

举个最简单的例子，Http协议够成熟了吧，实践得够多了吧，在生产环境中打磨得够久了吧，
但是万维网之父Tim Berners-Lee现在向网民道歉了，说:

引用

互联网网址前的双斜线“//”根本没有存在必要。
如果有机会再来一次，他会去掉“//”。

我举这个例子就是想说明实现一种功能可以采用各种技术实现策略，
只要在技术实现策略之间稍微斟酌一下就可以省掉没必要的东西，省得以后内疚。

如果你认为routes好，就应该像我那样给出示例代码，分析源代码实现原理，
告诉我Play这样做好在哪里，而不是以是不是“成品”的问题来搪塞，
这样会让我觉得你在有意回避问题的实质，
这是因为你对Douyu和Play的了解还不够，还只是停留在表面的认知。

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

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

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

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

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

83 楼 firebody 2009-12-05  

ZHH2009 写道

firebody 写道

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


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

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

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


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

firebody， 既然你是资深人员，那么你应该明白我在JavaEye做了什么，
更多的是分享自己的一些想法，而不是浮躁。

只不过这两天碰到帖子被隐藏，情绪受了点影响，才在JavaEye上多泡了点时间，
这不是在吹捧，也不是在大张旗鼓的宣传，因为16号我就已经谢绝JavaEye管理员的专访了，我认为不是时候，
我不是在浮躁，不是在吹捧，也不是在宣传什么。

既然你没这种心态那就好办，坚持你自己的路，少说多做就是了。

82 楼 Laynepeng 2009-12-05  

ZHH2009 写道

to Laynepeng

你说的东西挺有意思的，有些问题我会好好考虑，
就现在而言我对Douyu的愿景更像是个技术敷发器的研究项目，我本人也更喜欢搞研究。

等我把Douyu的基础框架完善后，把文档写全了，
我会把Douyu开源，然后建个专门的讨论区，让对Douyu感兴趣的人参与进来，
Douyu跟Play的设计目标和定位是非常不同的，
Douyu既可以纵向扩展直达编译器内部的每个细节，
也可以像Play一样当成一个胶水平台进行横向扩展。

因为在跟rich讨论过后，我最近还在尝试让Douyu与Tomcat这类传统的web容器兼容，
实现方案也很简单的，发布包不会依赖Javac编译器，
Javac编译器只在开发阶段是必须的，但是在生成环境中是不需要的。

这个尝试很让人鼓舞。douyu的设计的确非常不错，但是要注意bugs的控制，毕竟我还是觉得这里面有点复杂了，生成中间代码毕竟都是容易出问题的地方。。。

什么时候开源了我第一时间拿来看看。一些小的应用的确可以尝试一下。:)

81 楼 ZHH2009 2009-12-05  

firebody 写道

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


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

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

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


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

firebody， 既然你是资深人员，那么你应该明白我在JavaEye做了什么，
更多的是分享自己的一些想法，而不是浮躁。

只不过这两天碰到帖子被隐藏，情绪受了点影响，才在JavaEye上多泡了点时间，
这不是在吹捧，也不是在大张旗鼓的宣传，因为16号我就已经谢绝JavaEye管理员的专访了，我认为不是时候，
我不是在浮躁，不是在吹捧，也不是在宣传什么。

80 楼 firebody 2009-12-05  

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


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

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

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


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

79 楼 ZHH2009 2009-12-05  

to Laynepeng

你说的东西挺有意思的，有些问题我会好好考虑，
就现在而言我对Douyu的愿景更像是个技术敷发器的研究项目，我本人也更喜欢搞研究。

等我把Douyu的基础框架完善后，把文档写全了，
我会把Douyu开源，然后建个专门的讨论区，让对Douyu感兴趣的人参与进来，
Douyu跟Play的设计目标和定位是非常不同的，
Douyu既可以纵向扩展直达编译器内部的每个细节，
也可以像Play一样当成一个胶水平台进行横向扩展。

因为在跟rich讨论过后，我最近还在尝试让Douyu与Tomcat这类传统的web容器兼容，
实现方案也很简单的，发布包不会依赖Javac编译器，
Javac编译器只在开发阶段是必须的，但是在生成环境中是不需要的。

78 楼 ZHH2009 2009-12-05  

downpour 写道

ZHH2009 写道

我想你是站在应用层次的角度看问题的，而我是从底层的实现原理上看问题的，
如果是应用层次的比较我自认Play比现在的Douyu要高几个等级，
但是我的文章是从技术层面来比较的，我认为我可以去比较，因为我专门花了一星期研究Play的源代码实现，如果你也研究过Play的源代码，就像Laynepeng这位老兄一样(他为Play贡献过代码)，
那么你应该知道我在"6.控制器层：有必要RESTFul吗？有必要多加个routes配置文件吗? "这一节讲的是什么？讲的就是Play在
控制器层的源代码实现原理(包括动态编译)，我也是只在这一节明显提出Douyu比Play要好。

现在最大的问题就在于，或许在我看来，routes是一个亮点，而你认为没有必要。我想你也做过很多开发，应该也会承认，这应该属于一个哲学问题，不存在谁对谁错的问题，也没有谁优谁劣的问题。

举例来说，我以前为Struts2编写lighturl插件的时候，我自认为实现了非常优雅的CoC，有了这个，大家基本不需要配置文件了。同时，我还增加了支持url模板的Annotation，我认为是一个亮点，因为这已经和Rails中的routes没什么差别了。结果呢？我认为最应该成为亮点的地方，却被许多人提出诟病。因为我没有统一的配置，于是为他们的调试带来了极大的不方便，他们无法通过一个url来快速定位Action了，因为Annotation是不限制的。这个时候我才想起Rails中一个统一的routes文件进行配置的方便之处。

所以在你没有拿出一个我可以用的“成品”之前，我不愿意来和你讨论好与坏，因为在我看来，没有实践的东西，就没有发言权，没有在生产环境中打磨的东西，也没什么价值。或许它有很大的潜在价值，但是这些价值都是潜在的，也有可能成为垃圾的可能性。

所以我还是非常期待你的东西，哪天你把潜在二字去掉，我会从头到尾，认认真真使用你的框架来搭建一个demo系统。然后说说我的感觉。了解我的朋友也知道，如果我开始研究一个框架，一定会把它研究得很透。所以我想我到那个时候再来评论。

我说Play在应用层次方面比Douyu要高几个等级，
那是因为Play开发得早，功能比Douyu要多，比Douyu完善，所以Play能运用于生产环境，
但是并不代表在某一功能的技术实现策略上Play也比Douyu高，
比如在控制器层的动态编译和routes的问题上我都给了具体代码并详细对比了两者的技术实现策略。

你不能总是拿Douyu不是“成品”去判断技术实现策略的好坏，
也不能用你"为Struts2编写lighturl插件"的经验去判断，
因为Struts2或者lighturl插件跟Play和Douyu完全是两种不同的东西，没有可比性。

你说的实践问题，有没有在生产环境中打磨的问题是应用层次的问题，
这跟判断一种技术实现策略的优劣并不存在直接的关系，
举个最简单的例子，Http协议够成熟了吧，实践得够多了吧，在生产环境中打磨得够久了吧，
但是万维网之父Tim Berners-Lee现在向网民道歉了，说:

引用

互联网网址前的双斜线“//”根本没有存在必要。
如果有机会再来一次，他会去掉“//”。

我举这个例子就是想说明实现一种功能可以采用各种技术实现策略，
只要在技术实现策略之间稍微斟酌一下就可以省掉没必要的东西，省得以后内疚。

如果你认为routes好，就应该像我那样给出示例代码，分析源代码实现原理，
告诉我Play这样做好在哪里，而不是以是不是“成品”的问题来搪塞，
这样会让我觉得你在有意回避问题的实质，
这是因为你对Douyu和Play的了解还不够，还只是停留在表面的认知。

77 楼 Arden 2009-12-05  

今天刚发现play!一个非常严重的问题，修改了模版文件居然不能立即生效，必须重启play!后才行~~~

76 楼 Laynepeng 2009-12-05  

downpour 写道

ZHH2009 写道

我想你是站在应用层次的角度看问题的，而我是从底层的实现原理上看问题的，
如果是应用层次的比较我自认Play比现在的Douyu要高几个等级，
但是我的文章是从技术层面来比较的，我认为我可以去比较，因为我专门花了一星期研究Play的源代码实现，如果你也研究过Play的源代码，就像Laynepeng这位老兄一样(他为Play贡献过代码)，
那么你应该知道我在"6.控制器层：有必要RESTFul吗？有必要多加个routes配置文件吗? "这一节讲的是什么？讲的就是Play在
控制器层的源代码实现原理(包括动态编译)，我也是只在这一节明显提出Douyu比Play要好。

现在最大的问题就在于，或许在我看来，routes是一个亮点，而你认为没有必要。我想你也做过很多开发，应该也会承认，这应该属于一个哲学问题，不存在谁对谁错的问题，也没有谁优谁劣的问题。

举例来说，我以前为Struts2编写lighturl插件的时候，我自认为实现了非常优雅的CoC，有了这个，大家基本不需要配置文件了。同时，我还增加了支持url模板的Annotation，我认为是一个亮点，因为这已经和Rails中的routes没什么差别了。结果呢？我认为最应该成为亮点的地方，却被许多人提出诟病。因为我没有统一的配置，于是为他们的调试带来了极大的不方便，他们无法通过一个url来快速定位Action了，因为Annotation是不限制的。这个时候我才想起Rails中一个统一的routes文件进行配置的方便之处。

所以在你没有拿出一个我可以用的“成品”之前，我不愿意来和你讨论好与坏，因为在我看来，没有实践的东西，就没有发言权，没有在生产环境中打磨的东西，也没什么价值。或许它有很大的潜在价值，但是这些价值都是潜在的，也有可能成为垃圾的可能性。

所以我还是非常期待你的东西，哪天你把潜在二字去掉，我会从头到尾，认认真真使用你的框架来搭建一个demo系统。然后说说我的感觉。了解我的朋友也知道，如果我开始研究一个框架，一定会把它研究得很透。所以我想我到那个时候再来评论。

我不明白关于routes有什么好争论的，这东西基本上谁都说不服谁的问题，downpour说得很对。如果不喜欢用route，嫌配置麻烦，喜好契约，完全可以在route里面就这样写一句：

# Catch all
*       /{controller}/{action}                  {controller}.{action}

就可以满足需求了。。。

作为框架开发者，虽然要有自己的思想，但是也需要顾及不同用户的需要，功能放在那里，按需使用即可。

ZHH2009很强，douyu的技术的确非常创新，但是有些问题还是需要考虑的。不知道ZHH2009对douyu的愿景是什么？作为一个技术敷发器的研究项目，还是真的想把推广出去，为大家提供一个好用的框架？
如果是前者，ZHH2009现在做得很不错，可以把一些对javac的研究成果，或者一些架构的新思想和大家share一下，但是如果真的想把douyu推广出去，有些问题是要想的。

一个框架其实应该是简单的，轻量级的，在提供了一些很cool的功能的前提下，尽量使问题简化，把javac包含过来会不会太复杂了？如果以后douyu推广出去后，将会运行在异构的环境下，会有各种奇怪的问题，怎样控制这些bug，使douyu稳定是一个考验。框架应该是尽量简单从而稳定的，尽量不要因为框架的bug而造成用户的系统出现问题。我眼中，框架的最大作用是使不同的人，不同水平的人写出来的代码基本一个样，使系统维护，或者项目成员的更替不会受到影响——这个才是框架最重要的作用。然后就是尽量把业务不相关的问题交给稳定的框架完成，我们只做最简单的事，减少错误的出现。当然这个框架能提供一些便捷给我的团队开发，使开发更高效，那是更好。而到底底层是什么，我根本不会去关心。
举个例子，我为什么会接触Play？很简单，我们公司刚好要做一个小应用，非常小的应用，一开始我想ROR解决的；但是这里面需要用到我们原来的一个lib，是java的。但是这个小应用太小，我不想给它配一套SSH，不值得，结果就发现了Play，很不错，就使用上了。。。
然后刚好GAE推出java版本，我发现Play支持GAE，所以就用它简单作了个blog。。。中间出了点问题，就帮他们给解决了。。。

Play很简单，而且下下来的包就包括源代码，他的技术并不先进，但是的确可以做一些很cool的事情，比较适合小的web应用，Bort本身就是个web designer，做些小网站的，所以他的框架的目标用户群也是这种小应用。。。我记得jdon的banq也对play写过一篇文章，说Play很不错，但是没有DDD，没有domain层，我当时就无语了。。。

第二点，我觉得现在douyu在运营上面来看，是不正确的。一个新生事物要发展最好要先在大树底下慢慢发展。MS当年也是先在IBM底下低三下四地活了好多年；等他做大了，才可以不管标准，捆绑IE，绑架web标准。我个人觉得douyu现在还是先要尽量做到能够运行在主流web container底下。。。（如果我没记错，应该是不可以的吧？）Play推广过程中，能够打成war包就是一个大卖点，因为很少人会真正用那个内置的container的。牛如GWT，那个内置的container也不过是给你测试用用。。。另外Play!的大发展，很大程度在于它第一时间支持GAE，如果你去他的group看，一半以上的问题都是关于在GAE上运行问题的，你想想这给它带去了多少用户？为了满足这个需要，硬是在1.0版本底下加上Siena，用来支持big table。。。
Play的胶水，其实就是为了满足更多人的不同需要，支持Spring, openid, NoSql, GAE。。。因为他知道满足越多人的需要，就会给它带来越多用户。。。所以她胶水，他的确很胶水，他的代码很少，按你说法就10000多行而已。。。

第三，关于外部包的问题。这是一个buy or make的经济学问题。不讨论了。。。

第四，对于一个设计，很难讨论到底哪种好，经常开会的时候，拍桌子，大吼也常有的事情。很难讨论的，继续是那个驰名的banq，他骂Spring够多了吧？Spring算是很经典的框架了，但是从不同角度来看，还是能扯出一堆又一堆的问题，坏味。。。但是又如何，Spring赢得了用户，改变了大家的开发模式，同时也为自己获取大量金钱。。。这些东西没多少意思的。。。

我真的很希望douyu能继续下去，毕竟国内很缺少好的开源项目，再说我们的家乡还比较近，哈哈~~

75 楼 downpour 2009-12-04  

ZHH2009 写道

我想你是站在应用层次的角度看问题的，而我是从底层的实现原理上看问题的，
如果是应用层次的比较我自认Play比现在的Douyu要高几个等级，
但是我的文章是从技术层面来比较的，我认为我可以去比较，因为我专门花了一星期研究Play的源代码实现，如果你也研究过Play的源代码，就像Laynepeng这位老兄一样(他为Play贡献过代码)，
那么你应该知道我在"6.控制器层：有必要RESTFul吗？有必要多加个routes配置文件吗? "这一节讲的是什么？讲的就是Play在
控制器层的源代码实现原理(包括动态编译)，我也是只在这一节明显提出Douyu比Play要好。

现在最大的问题就在于，或许在我看来，routes是一个亮点，而你认为没有必要。我想你也做过很多开发，应该也会承认，这应该属于一个哲学问题，不存在谁对谁错的问题，也没有谁优谁劣的问题。

举例来说，我以前为Struts2编写lighturl插件的时候，我自认为实现了非常优雅的CoC，有了这个，大家基本不需要配置文件了。同时，我还增加了支持url模板的Annotation，我认为是一个亮点，因为这已经和Rails中的routes没什么差别了。结果呢？我认为最应该成为亮点的地方，却被许多人提出诟病。因为我没有统一的配置，于是为他们的调试带来了极大的不方便，他们无法通过一个url来快速定位Action了，因为Annotation是不限制的。这个时候我才想起Rails中一个统一的routes文件进行配置的方便之处。

所以在你没有拿出一个我可以用的“成品”之前，我不愿意来和你讨论好与坏，因为在我看来，没有实践的东西，就没有发言权，没有在生产环境中打磨的东西，也没什么价值。或许它有很大的潜在价值，但是这些价值都是潜在的，也有可能成为垃圾的可能性。

所以我还是非常期待你的东西，哪天你把潜在二字去掉，我会从头到尾，认认真真使用你的框架来搭建一个demo系统。然后说说我的感觉。了解我的朋友也知道，如果我开始研究一个框架，一定会把它研究得很透。所以我想我到那个时候再来评论。

74 楼 ZHH2009 2009-12-04  

downpour 写道

那个帖子的隐藏，有15票的权重是我投的。这里我要首先说句抱歉，因为我没注意到我的权重那么大。当时我已经见到一些精华，我不希望一下子又看到一个吵架帖，于是做了一个隐藏的投票。

不过在这里，我也需要提出我的一些建议，希望Douyu的作者认真思考：

1. 在你的Douyu没有发布一个可以用于生产环境的版本之前，我认为你不适宜去做比较。事实上，我在你的帖子中，也没有看到你提到Play!这个框架的许多优点，反而在任何地方都在提出对方框架的不足，这似乎也不太公平。

2. 你提出的许多问题是哲学问题，并不是一个谁对谁错，谁优谁劣的问题。所以，我认为你不适宜直接说某些地方是你的优点，而某些地方是人家的缺点。比如，在我看来，Play!的routes是这个框架的亮点，却被你认为是没有必要的东西。你说我和你到底谁是对的，谁是错的？我想还是需要更多的由使用者来决定。

我想你是站在应用层次的角度看问题的，而我是从底层的实现原理上看问题的，
如果是应用层次的比较我自认Play比现在的Douyu要高几个等级，
但是我的文章是从技术层面来比较的，我认为我可以去比较，因为我专门花了一星期研究Play的源代码实现，如果你也研究过Play的源代码，就像Laynepeng这位老兄一样(他为Play贡献过代码)，
那么你应该知道我在"6.控制器层：有必要RESTFul吗？有必要多加个routes配置文件吗? "这一节讲的是什么？讲的就是Play在
控制器层的源代码实现原理(包括动态编译)，我也是只在这一节明显提出Douyu比Play要好。


在"10.视图"这一节我就明显指出了Play比Douyu做得更好:

ZHH2009 写道

Play借助Groovy实现了一套模板标记，从功能的完备程度上甚至还比不上freemarker，
当然Play的功能比Douyu肯定要多了

其他的小节我基本上没说哪个好哪个坏，
我只是给出了一些我设想的方案，就是那些绿色字体的内容。

downpour 写道

3. 你的框架是近年来在Javaeye这个平台上宣传的质量最高的开源框架。不过我的想法呢，还是说你能够尽快给我们一个正式版，并提供一些可靠的测试数据，告诉我们，我们有足够的理由可以连Tomcat都抛弃了，而使用你的框架来进行企业开发。如果有这些数据的充实，我想我会非常乐意来用你的框架试试。

我也很感谢JavaEye，16号那天JavaEye管理员说要专访我，但是我谢绝了，因为我认为还不是时候，
我一向是个低调的人，我之所以发"Douyu vs Play!"这个帖除了回复这个帖之外，
先前听说Play这个框架跟Douyu差不多，然后就去看了，接着又一时口快说要写个比较帖，
说出的话不好反悔，只好花一天时间写了篇文章。

不管怎么样我都会好好开发Douyu，
不为别的，这是我的兴趣，没人督促我，我也会不断的做下去。

downpour 写道

我已经向管理员申请恢复你之前的帖子，再次表示抱歉。

我并不在意论坛等级或积分什么的，花了一整天认认真真的找资料写篇文章并不容易。
我不会记仇，只要说明问题了什么事都好说。

73 楼 downpour 2009-12-04  

那个帖子的隐藏，有15票的权重是我投的。这里我要首先说句抱歉，因为我没注意到我的权重那么大。当时我已经见到一些精华，我不希望一下子又看到一个吵架帖，于是做了一个隐藏的投票。

不过在这里，我也需要提出我的一些建议，希望Douyu的作者认真思考：

1. 在你的Douyu没有发布一个可以用于生产环境的版本之前，我认为你不适宜去做比较。事实上，我在你的帖子中，也没有看到你提到Play!这个框架的许多优点，反而在任何地方都在提出对方框架的不足，这似乎也不太公平。

2. 你提出的许多问题是哲学问题，并不是一个谁对谁错，谁优谁劣的问题。所以，我认为你不适宜直接说某些地方是你的优点，而某些地方是人家的缺点。比如，在我看来，Play!的routes是这个框架的亮点，却被你认为是没有必要的东西。你说我和你到底谁是对的，谁是错的？我想还是需要更多的由使用者来决定。

3. 你的框架是近年来在Javaeye这个平台上宣传的质量最高的开源框架。不过我的想法呢，还是说你能够尽快给我们一个正式版，并提供一些可靠的测试数据，告诉我们，我们有足够的理由可以连Tomcat都抛弃了，而使用你的框架来进行企业开发。如果有这些数据的充实，我想我会非常乐意来用你的框架试试。

我已经向管理员申请恢复你之前的帖子，再次表示抱歉。

72 楼 ivorytower 2009-12-04  

ZHH2009 写道

我的回复在
http://www.iteye.com/topic/540417

昨天花了一天写篇文章，刚上来JavaEye看看，10分钟前还好好的，一个投隐藏的都没有，
过了10分钟后马上变隐藏，我知道很多人看我不爽，
但无声无息的把我的文章隐藏掉实在让我觉得不可思义。


也需我文章中提到的用语过份了点：
比如"胶水框架"
和下面这句话:

ZHH2009 写道

之所以出现两者并存的情况只是因为Play是个胶水框架，
也许是Play的开发人员不想修改或没能力修改eclipse jdt。

胶水框架又不是贬意词，Python语言还常称为胶水语言呢，
胶水只不过是用来形容一个东西的特点罢了。

相比这篇文章的用语，我想我不为过。


既然如些，也不用在讨论什么了。

真可惜。只是一份很好的对比而已，虽然有点过而已，但站在我自己的角度看是一篇很好文章。我自身用的是Java的SSH框架开发。Play还没接触过，但就斗鱼来说，刚看到那时着实让我兴奋。
希望看到实质成功。。支持

71 楼 daquan198163 2009-12-04  

开源社区里都有个“吃狗粮”的习惯，
建议斗鱼的作者也花些时间用自己的框架开发个杀手级的Demo，
如果效率能成倍提高，代码减少一半以上，自然可以让质疑者闭嘴。
其实这个建议适用于任何一个框架的开发者。

70 楼 epanthere 2009-12-04  

stray说的很对了  随便投隐藏跟剥夺人家的说话权利没多大差别

69 楼 stray 2009-12-04  

macadam 写道

ZHH2009 写道

但是在网上，特别是在技术方面，我就很容易激动，我不会动不动就随意BS别人，
但是也无法容忍别人对我指指点点，除非你真的在技术超过我，那我随你BS，你骂我是垃圾我都接受。

关键问题是 技术再牛 也不代表观点就一定正确~

观点不正确不等于你可以剥夺人家的说话权利。

68 楼 macadam 2009-12-04  

ZHH2009 写道

但是在网上，特别是在技术方面，我就很容易激动，我不会动不动就随意BS别人，
但是也无法容忍别人对我指指点点，除非你真的在技术超过我，那我随你BS，你骂我是垃圾我都接受。

关键问题是 技术再牛 也不代表观点就一定正确~

67 楼 stray 2009-12-04  

<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>