读阿里巴巴Java开发手册v1.2.0之工程结构有感【架构篇】

字体大小: 中小 标准 ->行高大小: 标准

首先,把昨天那俩条sql语句的优化原因给大家补充一下,第一条效率极低,第二条优化后的,sql语句截图如下:

经过几个高手的评论和个人的分析:

  第一条sql语句查询很慢是因为它首先使用了in关键字查询,导致全表扫描,其次我那条sql语句的写法上,是通过子查询根据某一个字段去不断匹配后面查询到的集合数据,最后得到查询结果,这一系列操作下来效率上去才怪呢。

  但是第二条sql语句是通过连接查询,根据建立了索引的字段来等值匹配,最后得到查询结果,速度杠杠的。(一次小小的优化经历,学到了)。

 

  今天(2017-05-24)在微信公众号上终于等到阿里巴巴集团开源的Java开发手册更新了,从地铁上一路看到公司,真的学到了,人家的开发规约真的是好,讲的很细,很注重细节,这就是差距啊,下面给大家简单总结一下吧(手册原件如果需要,请留言)。

  它的名字是《阿里巴巴Java开发手册v1.2.0》,距2017-02-09发布的第一版已经有6个历史了,它的总体结构分为五大部分:编程规约、异常日志、MySQL数据库、工程结构和安全规约。今天我主要给大家分享总结了工程结构,因为我五一前刚给公司开发了一套内网数据录入系统,虽然没用到什么大的框架和潮流的技术,但是麻雀虽小五脏俱全啊。包括表结构、工程搭建和业务梳理都是自己一个人在开发,当时在开发的时候也是感觉很孤独,因为项目组的其他人都有战友配合作战,而我就一个人,还有页面的调试和美化都是我一个人在搞,在此声明一下,我不是在抱怨,反而很珍惜这种开发机会,真的会沉淀很多东西,谢谢公司。

  切入正题吧,今天给大家分享的是工程结构这块的一些个人总结。

1、项目应用分层:

这里主要给我们讲述了一下,一个项目理想化的项目架构图,和我们平时开发的项目结构稍稍不同,毕竟人家的架构思维那是相当的高啊,这还是最基础的架构图呢。

上图默认上层依赖于下层,箭头关系表示直接依赖。

  开放接口层:可直接封装service层接口中的方法暴露成RPC接口/服务,通过web封装成http接口,最后进行网管控制、流量控制等。

  终端显示层:各个端的模板渲染并执行显示的层。当前我们主要接触的是js渲染、jsp渲染和移动端渲染等。

  web层:主要是对访问控制进行转发,各类基本参数校验,或者不复用的业务简单处理等。

  service层:相对具体的业务逻辑服务层。

  manager层:通用业务处理层,它有如下特征:1、对第三方平台封装的层,预处理返回结果及转化异常信息;2、对service层通用能力的下沉,比如缓存方案、中间件通用处理、3、与dao层交互,对多个dao的组合复用。

  dao层:数据访问层,与底层MySQL、Oracle、hbase数据库进行数据交互。

  外部接口或第三方平台:包括其他部门的rpc接口,基础平台,其他公司的http接口。

 

  以上都是阿里项目的工程架构,有一点不同的是我们平时通用的是controller层、service服务层和dao数据访问层,但是他们这里提出了manager层,将一些业务通用的处理方式和需要多个dao组合复用的结果抽取到该层,个人感觉在项目维护上很方便,以前我们都是按模块划分,将各个模块的业务逻辑都往service层堆上去,这样其实也没什么不好,但是我们感觉试着将业务层通用的业务抽取一下,刚才还琢磨着把我前俩天写的项目重构一下,最后还是等到端午吧,也好好模仿一把阿里,哈哈哈。

2、项目异常分层处理规约:

  因为dao数据访问层产生的异常很多,类型也很多,无法用细粒度的异常进行处理,所以直接将异常丢给service层,为啥要将数据访问层的异常丢到manager/service层,因为通常在manager/service层中会有日志打印,不管是发生异常还是异常抛出,都会时刻记录运行情况到日志文件中去,要是刚才在dao层也将异常打印,又因为dao和service是同台服务器,这样就相当于打印了2次日志,浪费性能和储存。

  service产生的异常必须记录到磁盘日志文件中去,尽可能带上参数信息,相当于保护案发现场。

  web层大哥们,不能在爽啦,必须处理了,如果产生的异常会导致页面的正常渲染,则采用拦截器或异常处理的方式,跳转到异常错误友好页面,加上友好的错误提示信息,最后还要在开发接口层将产生的异常处理成错误码和错误信息返回。

3、分层领域模型规约:

  我们以前的项目中我见过有3类模型类,第一类是web层与视图层传递参数的query类,第二类是与数据表对应的pojo类,第三类是为了响应数据定义的扩展vo类。

  下面我们来看看阿里是如何将模型进行规约的,我感觉非常啰嗦但是非常好,其实很多电商公司也估计是这么做的,我之前接触的一个电商项目大概就是这种设计,好长时间了记不清了:

  DO(data object):与数据库中的数据表一一对应,通常是应用于数据访问层dao中用于向上传输数据源对象。

  DTO(data transfer object):数据传输对象,该模型类主要是应用于service层和manager层,将service层和manager层业务处理后进行向外传输对象。

  BO(business object):业务对象,主要是service层输出的封装的业务逻辑的对象。

  Query:数据查询对象,各层接受上层传递过来的多个参数并将这些参数封装到query对象中。

  VO(view object):视图层对象,主要是web层向视图层传输的数据对象。

4、二方库依赖:

  定义GAV遵从一下规则:

  (1)、GroupID格式:com.{公司/BU}.业务线.[子业务线],最多四级。

  (2)、ArtifactID格式:产品线名-模块名。注意:语意不重复不遗漏,最好到中央仓库中去查证一下。

  (3)、Version格式:版本号根据自己公司的规定。

 

最后给大家送上几条建议,也是在手册中看到的,只不过写到这儿印象比较深刻,还没忘就给大家写在这儿吧:

一:数据订正时,在调用修改和删除方法之前,最好先查询要修改或删除的记录是否存在,确认无误后再进行更新。

二:在查询数据时能避免使用IN关键字就避免,是在避免不了,则需要仔细评估IN后边的数据集合中总数是否超过1000,最好控制在1000以内,我上次的优化经历起源于它,就是匹配的集合数据远远超过1000条,最后导致查询效率极低。

三:sql.xml文件中配置参数尽量使用#{},尽量不要使用${},容易造成sql注入问题。

四:接口过时必须加@Deprecated注释,并且添加注释清晰地说明替代旧接口的新接口或服务。

五:一般不要在pojo类中定义属性的变量时,建议不要加is前缀,但是在数据表中定义属性对应的字段是尽量加上is_前缀,原因是:如果在给属性的变量名加上is前缀极可能会发生,部分框架解析时会引起序列化错误。

六:在定义项目中的包结构时,统一使用小写并单数形式。

七:service层和mapper接口中定义的方法,建议不要写修饰符,目的就是代码结构看着简单,阿里给出的解释,所以我就把我以前的都删掉了,好习惯就应该从现在开始。

八:如果项目中要实现分页逻辑,如果在判断总记录数为0时,则直接返回,避免执行后面的分页语句,给大家送张截图,是我前几天自己写的分页逻辑:

复制代码
1   @Override
2     public List<Task> findOrdersByUserId(Task task,Page page) {
3         int count = vinTaskMapper.countOrdersByUserId(task);
4         page.setMaxRow(count);
5         if(count == 0){
6             return new ArrayList<Task>();
7         }
8         return vinTaskMapper.findOrdersByUserId(task,page);
9     }
复制代码

九:禁止使用存储过程,因为难以调试和扩展,更没有移植性。

 

好了,就总结到这儿吧,这里虽然没什么干货和技术要点,但是我的目的是给大家分享一点编程习惯,具备好的代码风格是作为一个优秀程序员的基本素能,最后希望大家写出来的代码能够越看越美,越看越想看,哈哈哈。

此文章由 www.phpgz.com 收集整理 ,地址为: http://www.phpgz.com/htmls/70782.html