该帖已经被评为良好帖
|
|
---|---|
作者 | 正文 |
发表时间:2009-12-01
最后修改:2009-12-01
今天又看到了有同学开发了一个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君继续,作为一个先行者的勇气,望你能做出一个优秀的框架! 声明:ITeye文章版权属于作者,受法律保护。没有作者书面许可不得转载。
推荐链接
|
|
返回顶楼 | |
发表时间:2009-12-01
play!的测试的确是非常非常的不错。
对于static的方法,我觉着Controller都是静态的,没什么不好的。不认为Controller中有什么是必须通过继承来解决的。 |
|
返回顶楼 | |
发表时间:2009-12-01
这一点我同意的你的观点,static带给了Play很多便利.但是这个确实是一个缺陷,当前我看到Play最大的缺陷就是这一点.
|
|
返回顶楼 | |
发表时间:2009-12-01
Play!的确是比较不错的框架,插件式组件支持也很不错。例如使用Siena module后,Model层就可以很方便的使用no-sql了。。。
|
|
返回顶楼 | |
发表时间:2009-12-01
最后修改:2009-12-01
有理有据的帖子,但是douyu本身还只是起步阶段,现在比较还嫌太早,对douyu略显不公平,期待douyu作者的回复
|
|
返回顶楼 | |
发表时间:2009-12-01
douyu是很有特点的,在这里并没有提出来。我觉得,是不完整的。
|
|
返回顶楼 | |
发表时间:2009-12-01
楼主,这有啥好比较的。。。
|
|
返回顶楼 | |
发表时间: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之类是非常容易的 |
|
返回顶楼 | |
发表时间:2009-12-01
cloud21 写道 douyu是很有特点的,在这里并没有提出来。我觉得,是不完整的。
你可以进行补充,大家一起讨论它的价值 此贴只是想客观的比较一下Douyu和Play,也希望ZHH能获得一些有用的信息. |
|
返回顶楼 | |
发表时间: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对象,更麻烦 第三个问题,目前没有,理由同一 |
|
返回顶楼 | |