|
该帖已经被评为隐藏帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2010-11-09
有哪个前辈能发个技术贴对比下 play 和Grails？
|
| 返回顶楼 | |
|
发表时间：2010-11-09
lookdd1 写道 yuxie 写道  .net就没有这个烦恼。。
public string ID { get; set; }
上边的代码已经包含了属性和getter/setter。。。Play这么做也是给Java逼出来的。。 这篇帖子无意把战火引入语言孰优孰劣之争,当然，我承认.net就语法本身来说,应该比java先进些吧  。。。
.NET是我见到的最彪的语言了 |
| 返回顶楼 | |
|
发表时间：2010-11-09
借问你们用play！来开发什么级别的应用？
|
| 返回顶楼 | |
|
发表时间：2010-11-09
|
| 返回顶楼 | |
|
发表时间：2010-11-09
play我还没敢用它正式搞点啥。。不放心。不敢冒险。最多只能帮其他人写个小程序 ，做做毕业设计而已。
|
| 返回顶楼 | |
|
发表时间：2010-11-09
最后修改：2010-11-09
lookdd1 写道 downpour 写道 lookdd1 写道 downpour 写道 使用Play Framework的同学应该直接使用Ruby。用一个动态语言来抨击一个静态语言是不公平的。如果你习惯动态语言的编程方式，为什么不直接使用动态语言呢？
我想play相较于rails最大的优势就是它易学易用,即使新手也可以在短时间内学会开发，而且java社区中那么多成熟的第三方库都可以为play所用,它还基本上拥有了rails的优点，您觉得在这种情况下我还有必要冒风险使用rails吗？ 用rails是风险？这种观点实在是让人不可理解。Play Framework的多数思想来源于rails，由于静态语言的实现限制，Play直接打破了Java所谓的封装性，面向对象的特性。一个编程语言的根基都已经被破坏了，你还指望基于这种理念开发出来的框架将来能如何发展？ 易学易用？2个东西如此之像，我真想不到为什么rails在你心中就不那么易学易用了。至于rails借助ruby动态语言的一些特性而独有的例如“植入”的特性，在Java中几乎不可实现。所以用了Java再用play，就相当于你穿了羽绒大衣游泳一样，纯属多余。 动态语言与静态语言各有优势，这一点无法否认。所以没有必要用静态语言优势的地方去做动态语言该做的事情，这属于不合理行为。 1、神马封装性,面向对象啥的与我无关,只要它搞出来的代码在生产环境中不会因为它的这些特殊特性引起使用或者性能上的一些瓶颈即可。所以,play!framework那么多的static,那么多的hack迄今为止我没有发现任何不妥。 2、我大体学过ruby和rails,您觉得让一个java开发人员转向ruby/rails 快呐？还是从ssh转向play快呐？起码我们的这个小团队(全部高中学历)基本都可以畅通无阻的使用play。还有一些rails中的魔法play肯定学不来,这个就要看取舍了。目前的play在我看来，应该基本拥有了和rails的类似的开发效率，同时拥有了rails不具备的大量的java廉价劳动力，大量的第三方成熟的库，成熟的IDE，静态语言较动态语言的优势。 至于静态语言干动态语言的事情,还是那句话，只要它不影响性能，不会引起使用上的瓶颈。那就不在我的考虑范围之内。合适不合适不是随口说出来的。 目前来看，play是集rails的便利以及java的成熟同时与两边考量折中之后的成果。至于谁想选哪个,谁能用的了哪个,这个需要看自己团队的实际情况了。 三鹿奶粉 也有奶粉成份 少量服用也死不掉人 抓到篮子就是菜得态度 所以一辈子也就是play play |
| 返回顶楼 | |
|
发表时间：2010-11-09
lookdd1 写道 ironsabre 写道 起码我们的这个小团队(全部高中学历)
----------------------------- 你们这个什么团队，这么神奇？ 哈哈。。么什么神奇，都是培训生，除了高中还有中专的。。。  我震惊了..... |
| 返回顶楼 | |
|
发表时间：2010-11-09
易卡螺丝君 写道 三鹿奶粉 也有奶粉成份 少量服用也死不掉人 抓到篮子就是菜得态度 所以一辈子也就是play play 这种万能回帖同样适用于抨击ssh和rails |
| 返回顶楼 | |
|
发表时间：2010-11-09
易卡螺丝君 写道 lookdd1 写道 downpour 写道 lookdd1 写道 downpour 写道 使用Play Framework的同学应该直接使用Ruby。用一个动态语言来抨击一个静态语言是不公平的。如果你习惯动态语言的编程方式，为什么不直接使用动态语言呢？
我想play相较于rails最大的优势就是它易学易用,即使新手也可以在短时间内学会开发，而且java社区中那么多成熟的第三方库都可以为play所用,它还基本上拥有了rails的优点，您觉得在这种情况下我还有必要冒风险使用rails吗？ 用rails是风险？这种观点实在是让人不可理解。Play Framework的多数思想来源于rails，由于静态语言的实现限制，Play直接打破了Java所谓的封装性，面向对象的特性。一个编程语言的根基都已经被破坏了，你还指望基于这种理念开发出来的框架将来能如何发展？ 易学易用？2个东西如此之像，我真想不到为什么rails在你心中就不那么易学易用了。至于rails借助ruby动态语言的一些特性而独有的例如“植入”的特性，在Java中几乎不可实现。所以用了Java再用play，就相当于你穿了羽绒大衣游泳一样，纯属多余。 动态语言与静态语言各有优势，这一点无法否认。所以没有必要用静态语言优势的地方去做动态语言该做的事情，这属于不合理行为。 1、神马封装性,面向对象啥的与我无关,只要它搞出来的代码在生产环境中不会因为它的这些特殊特性引起使用或者性能上的一些瓶颈即可。所以,play!framework那么多的static,那么多的hack迄今为止我没有发现任何不妥。 2、我大体学过ruby和rails,您觉得让一个java开发人员转向ruby/rails 快呐？还是从ssh转向play快呐？起码我们的这个小团队(全部高中学历)基本都可以畅通无阻的使用play。还有一些rails中的魔法play肯定学不来,这个就要看取舍了。目前的play在我看来，应该基本拥有了和rails的类似的开发效率，同时拥有了rails不具备的大量的java廉价劳动力，大量的第三方成熟的库，成熟的IDE，静态语言较动态语言的优势。 至于静态语言干动态语言的事情,还是那句话，只要它不影响性能，不会引起使用上的瓶颈。那就不在我的考虑范围之内。合适不合适不是随口说出来的。 目前来看，play是集rails的便利以及java的成熟同时与两边考量折中之后的成果。至于谁想选哪个,谁能用的了哪个,这个需要看自己团队的实际情况了。 三鹿奶粉 也有奶粉成份 少量服用也死不掉人 抓到篮子就是菜得态度 所以一辈子也就是play play  有啥好争的，只要能满足需求，用啥都行
|
| 返回顶楼 | |
|
发表时间：2010-11-09
需求？
一个压力测试就crash掉了 和我谈什么需求 |
| 返回顶楼 | |
