应该是很久以前已经知道有一个叫做play的框架，当时感觉这又是一个struts类的MVC框架，而且play这个名字也太平凡了，根本不能引起兴趣。后来一直关注的IDEA升级到版本11的时候，赫然发现特性中标称支持play! framework了。什么样的一个框架能让一个IDE特别提供支持？
兴趣来了之后就跑去看了看开源中国社区的相关文章，看来还是红薯大力推荐的一个东西。中文资料太少了，几乎没有中文教程，甚至翻译过来的文档都很少，能找到跟play框架相关的只有一些简单介绍罢了。那就去官网看看吧，文档还是挺详细的，看起来也不吃力，很快就了解个大概。
结果真是越看越惊喜。据说设计思想上受ruby on rails很深，RoR没学过，不过跟之前初步接触的python 的django框架还是蛮相似，估计思想同出一脉吧。以前用struts2和hibernate时非常头痛的问题play居然轻松就解决了，甚至因servlet/jsp技术固有的限制而产生的问题也解决了，因为play框架甚至摆脱了servlet容器。使用play框架开发java web应用太方便了——这是我对play的初步印象。
play框架不但提供了很多机制简化了开发工作，而且在设计思想上也有大量突破。很多设计思想甚至是学习java语言的时候各种教材就给灌输进来的，什么软件分层啊，面向接口编程啊什么的。最早的时候因为水平有限，眼界也不够开阔，对于这些神秘的思想虽然不是很明白，但还是满怀敬畏的照做。不过我是喜欢寻根问底的人，一直以来从网上搜集大量资料来理解这些概念。
最有代表性的就是流行的软件分层和MVC的关系。我曾经花了大量心血去搞明白它们的关系。众所周知，软件分层一般是分成三层：表现层，业务逻辑层和持久化层；而MVC也是分三三层：视图，控制器和模型。可以强词夺理的认为软件分层和MVC不是一个层面的概念，没有可比性，但是硬要加以对应呢？表现层和视图很容易就对上了，但是控制器和模型呢？控制器是为了分离视图层和模型层的存在，但硬要对应起来的话也是应该归入表现层。对于模型有两种理解。从狭义上来说模型就是目前使用的pojo，这样视图、控制器和模型都有归属了，但是业务层和DAO没有对应起来。那么从广义上来说的模型其实应该囊括业务层和持久化层。
后来接触了些DDD（领域驱动设计）方面的东西，里面讲到领域模型时有个概念叫“贫血模型”，贫血模型只用来保存值，没有逻辑。其实我们现在在使用的pojo就相当于贫血模型。与此相对的就是包含业务逻辑的“充血模型”了。从这点上来看倒和我之前理解的狭义模型和广义模型对应起来了。
之前总觉得那些所谓的“最佳实践”提倡的设计模式真的是最合理的，那些高“可复用”、“可配置”和“可扩展”的设计其实并不是放在哪里都是“最佳”的。用后来接触的观点来说那是“过度设计”。做新版物流平台时，数据访问层和业务层没有采用面向接口的方式，开始还感觉有些心虚，感觉是在偷懒，但是后来事实证明了当时的选择是正确的。项目没有更换数据库，并且业务逻辑也没那么复杂多变（或者也可以说没什么所谓的业务逻辑）。
play框架也有些颠覆以往设计模式的理念，比如在控制器中直接调用模型的方法。为此play的文档中还特意搬出贫血模型说事。记得在马士兵的spring视频教程中有这么一段话，说的是你要写一个User类，应该再写一个UserDAO来创建User，如果直接在User中写add方法就比较怪异，因为你要添加一个别的用户还得先new一个新的用户出来才能调用add方法。不知道这个add方法是不是等同于save方法，如果是的话完全没有问题，调用user对象的save方法将自身的信息持久化到数据库一样很自然。
后来去看官方的英文文档，总的来说还是非常易懂的，这个神奇的框架不断的带给我惊喜，感觉对于我们正在做的这些项目来说，Play简直就是根救命稻草啊。一定想办法在部门内推广一下。