Java Web应用分层

Java Web目录结构

Java Web应用的目录有严格的存放规则。一般为：

WEB-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层，依此类推：

OpenApi层：可直接封装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向模板渲染引擎层传输的对象。

results matching ""

    No results matching ""