应用分层
隐藏下层业务逻辑的复杂性
提高系统的组件化和可维护性
为什么要分层?
可扩展性
可维护性
计算机领域的任何问题都可以通过增加一个中间层解决
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.公共二方库的行为不变