再说Play!framework

心动地方比如cache，job, email，这个跟框架核心没有啥关系吧，用不用都可以。

框架得有亮点，得轻量级，不要那种功能堆砌的框架

这就和spring一样啊。spring的核心是IoC 和AOP 。而它作为粘合剂的作用也是让人津津乐道的。它让使用第三方库更加简单。Play 的这些功能也只是集成的第三方的库。

盲目mixin就是盲目迷信，才是真的自寻死路。
C++er，请你们到csdn去自我感觉良好。

我只是说有 到你嘴里就程盲目了 这语文水平 真实让人叹为观止

拜托各位童鞋，请表吵架.....说说你们结论是怎么得来的对我们小白更有好处 

1. 我对play的static的理解是没有问题的，对于Controller或者是数据Model中是否应使用static方法，从来就有公论，不需要我在这里多做解释了。充血模型是Robbin提出为了加深大家对不同数据模型的理解，并不是一种正确的编程模式。一个面向对象的语言中，对象所拥有的操作范畴应始终保持在维护对象自身的状态而不是参杂任何的业务模式。多写几个应用程序的同学都会理解这才是Java的最佳实践。

2. 对象的生命周期的管理在rails里面也是有的。在Java世界，没有容器管理对象的生命周期几乎不现实，这是Java语言的特征决定的。你硬要说什么新时代，该消亡，我只能说你写的程序还太少，连这点基本的最佳实践都不明白。

结论就是与其邯郸学步rails 不如直接用rails

静态语言特性决定了 模仿rails的框架都是画虎类犬

rails的哪些东西模仿起来会比较 痛苦呢?

1．全栈式的MVC框架

2．约定优于配置


3．更少的代码

4．生成器

5．零周转时间

6．支架系统

1、大师，你连面向对象的基本概念都没搞清，别搞什么公论不公论了。充血模型是Robin提出的？老马听这话该吐血了。。。。去翻翻真正的公论《企业应用架构模式》吧，看看充血模型是谁提的，什么才是正确的编程模式。。

PS：八卦一下，即使在JE，先引出充血模型的也是T1老大，不是肉饼。

2、rails哪来的微容器管理声明周期？愿闻其详。。俺怎么看的rails程序都不用呢。恁老才没写过几天程序吧，看到个几年前的概念就当最佳实践了。。睁眼看看广大的世界吧。。其他的语言不管是类不类Java的，微容器管理生命周期的做法压根就没有。很简单的对象非要从容器里拿出来，闲着没事。。

人家是rubyer.
metaprogramming用起来极爽，可以开发出非常强大的框架。