PlayFramework1.2.7介绍及优化打包发布[一]

最新推荐文章于 2024-07-26 20:38:33 发布

ziya1992

最新推荐文章于 2024-07-26 20:38:33 发布

阅读量675

点赞数 3

分类专栏： PlayFramework1.2.7 文章标签： PlayFramework

本文链接：https://blog.csdn.net/zpl476045079/article/details/103126058

版权

PlayFramework1.2.7 专栏收录该内容

4 篇文章 1 订阅

订阅专栏

引言

PlayFramework是一个全栈式的开发框架,它与目前主流一些大框架比起来(Spring,SpringMVC)可能没有多少人认识,使用者也不多,但其易上手,配置简单化,封装度高,效率奇快的特点,可以为一些刚入门的web开发工程师提供许多帮助,可以提高许多开发效率.但是无论什么框架,都是有一些坑或者需要深入学习的场景,因此在项目开发过程中,我也尝试找了很多资料来比对play的一些优缺点.本文适合有一定框架使用基础的同学,好吧,废话有点多,我们进入正题.

初识Play

我们的项目是从一家外包公司接手的,据了解这家外包公司的项目基本都是使用play框架进行的开发,网上也能找到许多和这个项目有关的问题和资料(这边省略各种吐槽1000000字).项目主要是做网络借贷中介(P2P),初期因为急着上线,所以从某外包团队买了一套系统回来,后面发现外包的效率和功能不行,故决定自己组建技术团队,做二次开发.我"有幸"成为了公司技术部的第二位创始人,经历了公司整个项目的接手和改造.背景环境就啰嗦到这里

外包公司的代码结构还算清晰(后边发现这其实是因为play框架的包结构好,和外包没半毛钱关系),因为框架的关系,每个包下的内容不算太难理解,因为play严格按照mvc分层,因此这个陌生的框架对新手比较友好,开箱即用,网上也有许多的资料可以查询,我这边不详细介绍具体的使用方法,只简单说一下各个包中的内容:

本文使用的Play版本为较早的1.2.7版本,仅支持到JDK7,截至我写本文时,Play的最新版本已经到了2.7.3.

需要特别说明的是2.x版本与1.x版本可以说是完全2个不同的框架,感兴趣的同学可以进入Play的官网查看资料学习Play Framework官网

models

这个包中放具体的表结构实体,每个实体映射一张业务表,因为play内部持久层是用Hibernate去实现的JPA,因此数据库交互这块开发起来非常方便,它内部封装了几乎所有的数据库操作,我们甚至不需要写dao层就能实现基本的curd操作(这一点现在看来貌似是标配).

controller

放置控制器的包,里面包含所有前端的控制器.play的控制器有一个约定,所有方法必须是静态的,方法都必须有static关键字,否则报错.前后端的数据交互很简便,一个简单的render(obj1,obj2,…)就能将后台的数据传输到前端的模板中.

views

前端模板包,里面包含全部的模板引擎代码,后台render回来的数据可以在这里解析展示,play提供了许多方便的标签,方便开发,比如#{list}标签,#{include}标签等,这里不多介绍

一个完整的初始项目文件树状图如下:

├─app
│ ├─controllers
│ ├─models
│ └─views
│ ├─Application
│ └─errors
├─conf
├─lib
├─public
│ ├─images
│ ├─javascripts
│ └─stylesheets
└─test

编译打包

当我们码好代码准备上线时,第一个遇到的问题就是如何编译项目?如何发布项目?

play提供了简单的编译命令:

play war youapplication -o outpath

youapplication:是你项目的路径名称,表示你要打包编译哪个项目

-o:表示你要将打好后的包输出到那个路径

outpath:即是你的输出路径

编译好后我们只要像普通web项目一样,将包丢到tomcat中启动就可以了.

一个初次打包发布的过程,比较初级,也比较花时间.拿我们的项目来说,上千个java类和几百个模板页面,一次完整打包至少需要花费5分钟!虽然框架年份比较早,但这样的打包效率完全是在浪费我们的生命!优化问题,迫在眉睫.

首先我们要知道我们编译了什么,有哪些是我们需要的,哪些是我们不需要的

解决这个问题的最简单的方法是观察实践(这里属于我们内部自己的尝试研究,方法不是很科学,但实践验证了我们是正确的),先完整的编译出一个包,然后我们尝试删减其中我们觉得不需要的内容,启动项目,观察项目运行是否正常.play项目打包后,文件目录结构如下:

└─WEB-INF
├─application
│ ├─app
│ │ ├─controllers
│ │ └─views
│ │ ├─Application
│ │ └─errors
│ ├─conf
│ ├─precompiled
│ │ ├─java
│ │ │ ├─controllers
│ │ │ └─helpers
│ │ └─templates
│ │ ├─app
│ │ │ └─views
│ │ │ ├─Application
│ │ │ └─errors
│ │ ├─conf
│ │ ├─from_module_docviewer
│ │ │ └─app
│ │ │ └─views
│ │ │ └─PlayDocumentation
│ │ └─from_play
│ │ └─framework
│ │ └─templates
│ │ ├─errors
│ │ └─tags
│ ├─public
│ │ ├─images
│ │ ├─javascripts
│ │ └─stylesheets
│ └─test
├─classes
├─framework
│ └─templates
│ ├─errors
│ └─tags
├─lib
└─resources

依次查看包中的内容,可以发现,编译好的主要类文件都处在application包中,该包中的内容稍后会重点介绍.

classes包中主要包含了一些项目的配置文件的副本,观察发现,他和application包下的conf包中的文件一致,删除之后发现,play项目的配置文件主要是读取application包下的conf中的文件,因此classes可以认定是一个不需要的包.可以直接删除,不影响正常运行.
framework包下主要是play自带的模板引擎的标签和一些错误页面,需要保留,否则一些标签会无法使用
lib包是整个项目需要依赖的jar包,包括play的jar包和项目单独引入的jar包,必须保留.
resources包下是一些国际化的配置文件信息,若无国际化需求,可以删除.

我们重点的看一下application包下的文件.可以发现,该包下的内容和我们项目的包名结构是一样的,我们迭代更新,主要也是更新了这里面的内容.

微信截图20191118135143.png
这是我们的项目,其中lib包会在WEB-INF中显示

微信截图20191118135124.png

app文件夹下,我们意外的发现,整个项目的源码,.java文件竟然都在这里面!
这里是play的一个坑,或者说不合理的地方,这些原文件是我们可以直接删除的.我们需要保留的是views中的内容,因此我们保留views包作为模板更新的主要内容.后面会介绍怎么打包才能过滤掉这些没有编译的源码文件
然后我们看conf包下的内容,这个包顾名思义就是我们的配置文件了,千万不要和外面的calsses这个马甲包搞混了哦,这边也是我们亲自踩过坑得出的实践教训.一般我们对项目的改动无非是增加了路由,或者是修改了application.conf中的一些配置项.这边我给出一个比较好的实践.每次更新时整个替换routes文件,因为我们可能增加了许多路由.每次涉及到application.conf文件改动时,做好相应的记录,项目更新人员根据配置文件改动记录,去修改整个文件,而不是整个替换.这边为什么要这么做呢,为什么不是整个替换?因为我们日常开发过程当中是分开发环境和生产环境的,可能还有测试啊,巴拉巴拉一大堆,每个开发的环境都是不一样的,相应的配置文件中的信息也是不一样的,若有人疏忽提交了配置文件的改动,但是更新的人又没有注意,导致错误的配置文件上线,也会引起很多麻烦.play在多环境开发这块提供的不是很灵活,很多配置需要我们手动的区分,相比较传统spring框架来说,这一块也是paly的弱点和不足.
然后是test包,lib包和tmp包,**其中tmp包会存放项目的一些二进制文件,可以直接删除;**test包是存放项目单元测试的地方,可以删除,另外还有一些其他的例如日志logs包等,都是和项目无关的包,都是可以删除的
lib包是项目的jar包依赖,但是真正读取的jar包不是在application中的lib包,而是外层的lib包,因此也可以直接删除;
然后是静态资源包,public,这里面是我们用到的图片资源,css,js等静态资源,这里面的东西我们也是保留,整个替换到项目中就好,这个不涉及太多技术要点

最后,编译后的文件中,多出了一个precompiled文件夹,打开这个文件夹后,发现他下面包含了2个文件夹,java和templates.

java包中就是我们编译好后的class文件,我们后续若有补丁或者类文件的更新,其实就是更新了这里面的文件.
templates包中是play生成的缓存文件,其中包括路由routes文件的本地化缓存文件(conf),模板的本地化缓存文件(app),还有一些框架的模板标签缓存.我们打开conf/routes文件查看一下内容:
再打开app/views中的一个模板文件查看内容:
这些"乱码"既是play生成的缓存码,一份routes文件对应他自己的缓存,一份模板代码也对应了唯一的缓存.因此我们在迭代更新时,若改动了routes文件或者模板文件,则需要更新同名文件夹下同名文件中的内容,否则我们此次修改的内容将不会生效,因为play会优先读取缓存中的文件.注意!!:这里是清空,不是删除,若删除了这些文件,play会报template not found错误.