应用分层和maven

应用分层

隐藏下层业务逻辑的复杂性

提高系统的组件化和可维护性

为什么要分层?

可扩展性

可维护性

计算机领域的任何问题都可以通过增加一个中间层解决

MVC框架模式

view：面向客户（服务员）（jsp、模板、页面）

controller：全盘统筹（dispatcherservlet）

model：对页面支持的数据，对数据处理的业务逻辑（厨师）（service、pojo类）

（解耦：可维护、可扩展）

通用逻辑层（manager层）：相当于一个共用的service层，通用的业务逻辑（发邮件、发短信）

防腐层：调用第三方服务时用到，做一些状态码的转换，数据的转换与封装，转成我们系统用到的状态码、pojo。（严禁将第三方的状态码引入到我们的系统）

分层异常处理

DAO层：异常类型很多，不需要打印日志（向上抛出）。

Manager/Service层：必须记录出错日志到磁盘，尽可能带上参数信息，保护案发现场。

manager/service层跨服务器调用，则必写日志，日志在当前服务器记录。

Web层：绝不能往上抛异常，应跳转到友好错误页面,友好的错误提示信息（但是日志要记录）。

开放接口层.：将异常处理成错误码和错误信息方式返回

分层模型

（在每层都有的一个pojo类，用于层与层之间交换数据的对象）

DO (Data Object)：

此对象与数据库表结构一一对应，通过dao层向上传输数据源对象。

DTO (Data Transfer Object)：

数据传输对象，service或manager向外传输的对。（系统与系统之间（服务与服务之间）传递数据）（注意：数据传输涉及到对象的序列化和反序列化）（不是所有字段都传输）

BO (Business Object)：

业务对象，可以由service层输出的封装业务逻辑的对象（可以由多个DO对象组合，内部用的对象）（可以暴露所有字段）（不需要考虑序列化和反序列化）

Query：

数据查询对象，各层接收上层的查询请求。注意：超过2个参数的查询封装，禁止使用map类来传输（因为map的字段名称，key不确定，pojo对象的是确定的，写错就查询不到）

VO (View Object)：

显示层对象，通常是Web向模板渲染引擎层传输的对象。

Maven

管理项目中的依赖关系

对项目进行构建

（约定大于配置）

Maven的主要功能：

依赖管理

规范目录结构

完整的项目构建阶段（生命周期，通过插件实现）

支持多种插件

GAV（工程的坐标）：

G：groupId 组织id（网站倒写）

A：artifactId 项目id

V：version 版本号

json也是一种序列化的形式

Maven的依赖仲裁

1、按照DependencyManager版本声明进行仲裁。

（父工程里面声明所有，子工程不声明版本号，可直接用，修改时直接修改父工程即可）

2、如无仲裁声明，则按照依赖最短路径确定版本。

3、若相同路径，则按照第一声明优先原则。

解决依赖冲突：

1、找到依赖冲突（idea里面的maven里有show dependice工具，需要企业版）（maven helper插件也可以查看）

2、打包之前依赖排除，否则上线可能出现问题

3、升级过程中保证上下兼容（单独打包、中间层）

二方库依赖

定义GAV规则及版本号规则

定义二方库发布及引用规则

一方库：

本工程中的各模块的相互依赖

二方库：

公司内部的依赖库，一般指公司内部的其他项目发布的jar包

三方库：

公司之外的开源库，比如apache、google、 alibaba等发布的依赖

二方库GroupID、ArtifactID的定义

GroupID：

格式：com.{公司/BU（业务单元business unit）}.业务线[.子业务线]，最多4级

如：com.alibaba.dubbo.register

ArtifactID：

格式：产品线名-模块名

（语义不重复不遗漏，先到中央仓库查证一下）

dubbo-client

二方库中version的命名方式

主版本号.次版本号.修订号

主版本号：产品方向改变，或者大规模API不兼容，或架构不兼容升级

次版本号：保持相对兼容性，增加主要功能特性，影响范围极小的API不兼容修改

修订号：保持完全兼容性，修复BUG、新增次要功能特性等

注意：起始版本号必须为1.0.0，而不是0.0.1

二方库引用规约：

1.线上应用不要依赖SNAPSHOT版本

2.正式发布的类库必须去中央仓库查证，使RELEASE版本号有延续性

3.正式发布的类库版本号不允许覆盖升级

4.二方库的新增或升级，保持除功能点之外的其它jar 包仲裁结果不变

5.二方库里定义的枚举类型，参数中可以使用返回值不允许使用

6.依赖于一个二方库群时,必须定义一个统一的版本变量， 避免版本号不一致

7.禁止在依赖中出现相同的Groupld,相同的Artifactld,但是不同的Version

二方库引用建议：

1.底层基础技术框架、核心数据管理平台、或近硬件端系统谨慎引入第三方实现。

2.所有版本仲裁使用<dependencyManagement>语句块

3.二方库不要有配置项

4.不要使用不稳定的工具包或者Utils类

二方库发布原则：

1、精简可控原则：

1.移除不必要的API和依赖

2.只包含Service API、以及必要的工具类

3.如果依赖其它二方库，尽量provided引入

4.无log具体实现，只依赖日志框架

2、稳定可追溯原则：

1.记录每个版本的变化

2.二方库维护者

3.源码的位置

4.公共二方库的行为不变