play框架用起来（3）

1、MVC

Play应用遵循了MVC模式并将其运用到Web架构中。该模式将应用分为不同的层:表现层和模型层，其中表现层又可以分为视图层和控制层。

• 模型层是对数据的特定域呈现，域逻辑对原生的数据增加了含义（比如：计算今天是不是用户的生日，或者为购物车计算总价、税费、运费等）。大部分应用使用持久化存储机制（比如数据库）来保存数据。MVC并没有特别关注数据访问层，因为这被认为是底层的工作或者仅仅通过Model进一步封装而已。

• 视图层将模型渲染成有利于交互的形式（通常称之为用户界面UI），单个模型能够存在于多个视图，以此满足不同的需求。在Web应用中，视图通常使用Web格式来呈现信息，如HTML、XML、JSON等。但是还有一些用例中使用二进制的形式来表现，比如需要动态渲染图表。

• 控制层用来响应和处理事件（通常是用户的行为），并且可以通过方法调用对模型作出变更。在Web应用中，事件一般为HTTP请求。控制器会监听HTTP请求，从请求中获取相关的数据(例如查询字符串参数、请求报头等)，查询并返回数据或者直接改变底层模型对象。

      Play应用中的这些层都定义在app目录中，每个层都处于独立的包中。

app/controllers:

      控制器是Java类，包含了被声明为public static的Action方法。Action是当接收HTTP请求后被调用的Java入口，控制器类中的Java代码事实上不是面向对象的，而是面向过程的。Action方法从HTTP请求中获取相关数据，读取或者更新模型对象，并且返回封装成HTTP响应的结果。

app/models:

      域模型对象层是受用于Java语言面向对象特性的一组Java类，包含了数据结构和应用对数据的相关操作。当模型对象需要持久化存储时，可能还会包含一些JPA注解或者SQL语句。

app/views:

      大部分视图都使用Play提供的高效模板引擎生成，控制器从模型层得到想要的数据，然后应用模板修饰这些对象。该目录下通常包含HTML、XML、JSON等模板文件，通过模板引擎动态渲染模型。

2、生命周期

  Play是一个完全无状态的，只面向请求/响应的框架，所有HTTP请求都具有相同的处理流程：

1. 框架接收HTTP请求。
2. 路由组件找到最匹配的规则，接受并处理请求，随后调用相应的Action方法。
3. 执行Action中的应用代码。
4. 如果需要生成复杂的视图，使用模板文件进行渲染。
5. Action方法的返回结果（HTTP响应代码以及内容）被转换为HTTP响应。

      图2.2示意了HTTP请求处理的周期（Play应用的生命周期）：

3、应用层次结构

3.1 app目录#

      该目录下包含了所有可执行组件：Java源文件和视图模板。

提示：

读者可能会问.class文件在哪里？不用寻找编译后的Java文件，因为框架在运行时编译Java源文件并将编译后的.class文件以字节码缓存的形式保存在tmp目录下。从开发的角度讲，Play应用中主要的可执行组件为.java源文件，而不是编译后的.class文件。

      在app目录中有三个标准的包，每个包对应MVC模式中的一层，当然也可以增加自己的包（比如utils包）。其中视图包（views）可以进一步划分成多个子包：

• 按照模板约束规则，每个视图文件夹对应一个控制器，保存相对应的模板文件。

• 划分tags包，用于存放应用模板标签，比如可重用的模板片段等。

3.2 public 目录#

      保存在public目录中的都是静态资源，直接为Web服务所用（不需要服务器端做任何处理，直接将资源返回给客户端）。该目录拆分为三个标准子目录：images，javascripts和stylesheets 。开发当中应该尝试以这种方式组织静态资源，以便保持所有Play应用的一致性。

提示：

默认情况下public目录被映射为/public的URL路径，通过配置conf/routes文件可以改变路由规则。当然，也可以在该目录下使用更多的文件夹来存放静态资源为Web服务所用。

3.3 conf目录#

      该目录包含了与应用有关的所有配置文件，以下两个配置文件是必须的：

• application.conf：应用的主配置文件，内含标准的配置选项。

• routes：应用的路由配置文件，用于定义路由规则。

提示：

如果某个特定的应用需要增加一些额外的配置选项，可以将这些配置添加到application.conf文件中。应用程序代码中则可以通过Play.configuration.get("propertyName")方法读取对应的配置信息。如果一些类库需要独立的配置文件，可以将此文件放到conf目录下，该目录下的文件会被自动加载到应用的Java classpath中。

      当为应用增加额外配置文件时，需要对application.conf文件进行一些配置。使用@include标签可以将额外配置文件包含进来，比如在应用的conf目录下添加配置文件mime-types.conf，为应用定义额外的MIME类型：

# Web fonts
mimetype.eot = application/vnd.ms-fontobject
mimetype.otf = application/octet-stream
mimetype.ttf = application/octet-stream
mimetype.woff = application/x-font-woff

      在application.conf文件中需要添加如下行来包含上述的配置文件：

@include.mime = mime-types.conf

3.4 lib目录#

      该目录包含了应用所需的标准Java类库，通常为Play内置类库以外的jar包（由于Play自身内置了大部分常用的第三方类库，比如Hibernate，Log4j，Gson,Groovy等，因此只需要将开发过程中Play没有提供的jar包导入即可）。这些类库会被自动添加至Java classpath中。

4、DEV和PROD模式#

      使用Play开发应用不存在编译、打包、部署阶段，而且Play自身实现了两种不同的环境：开发阶段的DEV模式，应用发布的PROD模式。

补充：

应用可以在DEV或者PROD模式下运行，通过使用主配置文件中的application.mode属性来切换运行环境。当应用运行在DEV模式下时，Play会检查文件的变更并在有需要的时候进行热加载。而PROD模式对产品做了充分优化，Java源代码和模板文件只会在应用开启的时候被编译，之后以缓存的形式响应用户请求。

      在DEV模式下，如果源文件在应用运行期间被修改，源代码会重新编译并热加载到JVM。如果编译出错，浏览器中会显示出错原因以及准确的出错位置。同样地，模板文件也支持热编译和热加载。如图2.3所示。

 5、类增强

     也叫字节码增强，用于在运行时动态修改字节码，以便增加额外的方法、字段以及方法体内容等。Play中很多插件都包含用于在运行时更改应用实现类的增强器，比如为控制器类增加额外的方法。这便是Play不可思议的地方，也是非常核心的概念，掌握底层实现不可或缺的知识。

      内置的play.CorePlugin使用play.classloading.enhancers包提供的类增强器，为应用实现类动态增加代码，主要有以下几种：

• ContinuationEnhancer为控制器类增加continuations支持。
• ControllersEnhancer为控制器中的action方法增加线程安全功能，并为方法调用提供HTTP重定向支持。
• LocalvariablesNamesEnhancer用于跟踪控制器中的本地变量
• MailerEnhancer构建play.mvc.Mailer子类
• PropertiesEnhancer将所有应用类都装入有效的JavaBean，所有应用类相关的属性都注入到JavaBean字段中。
• SigEnhancer为每个类的签名生成唯一的hash值，从而实现自动重载。

      除此以外，play.db.jpa.JPAPlugin动态增强play.db.jpa.JPABase的子类，实现更为方便的JPA查询方法。这些通常都会应用到继承于play.db.jpa.Model的实体类中。上面提到的JPA查询方法都定义在play.db.jpa.GenericModel类中。

      如果需要自定义类增强器，只需要在插件的enhance(ApplicationClass)方法中使用play.classloading.enhancers.Enhancer类即可。

 MVC是Web应用开发当中很重要的层次化开发思想，Play通过清晰、直观的目录结构来遵循当前主流的开发方式。框架自动生成的配置文件(conf)，静态资源文件(public)，库文件(lib)，测试文件(test)等为开发者提供了很好的文件组织方式，使得所有Play工程项目具有标准、统一的应用结构。

      本章同时还介绍了Play应用的生命周期，区别于传统的Java框架，Play是完全无状态的，并且采用了路由机制。Play实现了两种不同的开发环境，在DEV模式下将精力集中在业务需求的实现，大大提高了开发效率；在PROD模式下，讲究应用的性能，重点关注应用的产品化特性。