Java Web应用分层
Java Web目录结构
Java Web应用的目录有严格的存放规则。一般为:
螢幕快照 2016-10-25 14.33.24.pngWEB-INF和META-INF是java web项目特有目录,放在根目录下,且全部是大写。
WEB-INF
基本内容有: /WEB-INF/web.xml Web应用程序配置文件,非常常用。这是一个XML文件,其中描述了 servlet 和其他的应用组件配置及命名规则。程序的入口描述也在这里。
/WEB- INF/classes/ 编译好的类文件会放到这个目录里。
/WEB- INF/lib/ 项目引用到的各种JAR文件,如spring jar文件
META-INF
存放程序入口信息,里面的MANIFEST文件记录了这些信息,可以归纳出下面几个大类:
一. 一般属性
1.Manifest-Version 用来定义manifest文件的版本,例如:Manifest-Version: 1.0
2.Created-By 声明该文件的生成者,一般该属性是由jar命令行工具生成的,例如:Created-By: Apache Ant 1.5.1
3.Signature-Version 定义jar文件的签名版本
4.Class-Path 应用程序或者类装载器使用该值来构建内部的类搜索路径 二. 应用程序相关属性
5.Main-Class 定义jar文件的入口类,该类必须是一个可执行的类,一旦定义了该属性即可通过 java -jar x.jar来运行该jar文件。 三. 小程序(Applet)相关属性
6.Extendsion-List 该属性指定了小程序需要的扩展信息列表,列表中的每个名字对应以下的属性
7.-Extension-Name
8.-Specification-Version
9.-Implementation-Version
10.-Implementation-Vendor-Id
11.-Implementation-URL 四. 扩展标识属性
12.Extension-Name 该属性定义了jar文件的标识,例如Extension-Name: Struts Framework 五. 包扩展属性
13.Implementation-Title 定义了扩展实现的标题
14.Implementation-Version 定义扩展实现的版本
15.Implementation-Vendor 定义扩展实现的组织
16.Implementation-Vendor-Id 定义扩展实现的组织的标识
17.Implementation-URL : 定义该扩展包的下载地址(URL)
18.Specification-Title 定义扩展规范的标题
19.Specification-Version 定义扩展规范的版本
20.Specification-Vendor 声明了维护该规范的组织
21.Sealed 定义jar文件是否封存,值可以是true或者false (这点我还不是很理解) 六. 签名相关属性 签名方面的属性我们可以来参照JavaMail所提供的mail.jar中的一段 Name: javax/mail/Address.class Digest-Algorithms: SHA MD5 SHA-Digest: AjR7RqnN//cdYGouxbd06mSVfI4= MD5-Digest: ZnTIQ2aQAtSNIOWXI1pQpw== 这段内容定义类签名的类名、计算摘要的算法名以及对应的摘要内容(使用BASE64方法进行编码)
系统分层
推荐如下分层结构,图中默认上层依赖于下层,箭头关系表示可直接依赖,如:OpenApi层可以依赖于Web层,也可以直接依赖于Service层,依此类推:
业务分层.jpgOpenApi层:可直接封装Service接口暴露成HSF接口,或者通过Web封装成http接口。 显示层:模板渲染层。当前主要是velocity渲染,JS渲染,JSP渲染等。 Web层:主要是对访问控制进行转发,各类基本参数校验,或者不复用的业务简单处理等。 Service层:相对具体的业务逻辑服务层。 Manager层:通用业务处理层,它有如下特征:
1) 对第三方平台封装的层,预处理返回结果及转化异常信息; 2) 对Service层通用能力的下沉,如缓存方案、中间件通用处理; 3) 与DAO层交互,对DAO的业务通用能力的封装。
DAO层:数据访问层,与底层Mysql、Oracle、Hbase、OB进行数据交互。 第三方平台:包括其它部门HSF开放接口,基础平台,其它公司的HTTP接口。
异常处理规约分层
在DAO层,产生的异常类型有很多,无法用细粒度异常进行catch,使用catch(Exception e)方式,并throw new DaoException(e),不需要打印日志,因为日志在Manager/Service层一定需要捕获并打到日志文件中去,如果同台服务器再打日志,浪费性能和存储。
在Service层往上抛的同时就必须使用日志,因为是RPC调用,可能本地出错,未必能正常反馈到业务端。这里就必须尽可能带上参数信息,相当于保护案发现场,并打印异常堆栈。
如果Manager层与Service同机部署,日志方式与DAO层处理一致,如果是单独部署,则采用与Service一致的处理方式。
Web层绝不应该继续往上抛异常,因为已经处于顶层,无继续处理异常的方式,如果意识到这个异常将导致页面无法正常渲染,那么就应该直接跳转到友好错误页面,尽量加上友好的错误提示信息。
openApi层要将异常处理成错误码和错误信息方式返回
领域模型分层
DO(Data Object)
与数据库表结构一一对应,通过DAO层向上传输数据源对象。
DTO(Data Transfer Object)
数据传输对象,Service和Manager向外传输的对象。
BO(Business Object)
业务对象。可以由Service层输出的封装业务逻辑的对象。
QUERY
数据查询对象,各层接收上层的查询请求。
注:超过2个参数的查询封装,禁止使用Map类来传输。
VO(View Object)
显示层对象,通常是Web向模板渲染引擎层传输的对象。