伦敦 伦敦00:00:00 纽约 纽约00:00:00 东京 东京00:00:00 北京 北京00:00:00

400-668-6666

分层编码

当前位置:主页 > 分层编码 >
分层编码

优秀的代码应该如何分层

  说起应用分层,大部分人都会认为这个不是很简单嘛 就`Controller`,`Service`, `Mapper`三层。看起来简单,很多人其实并没有把他们职责划分开,在很多代码中,`Controller`做的逻辑比`Service`还多,`Service`往往当成透传了,这其实是很多人开发代码都没有注意到的地方,反正功能也能用,至于放哪无所谓呗。这样往往造成后面代码无法复用,层级关系混乱,对后续代码的维护非常麻烦。

  说起应用分层,大部分人都会认为这个不是很简单嘛 就Controller,Service,Mapper三层。看起来简单,很多人其实并没有把他们职责划分开,在很多代码中,Controller做的逻辑比Service还多,Service往往当成透传了,这其实是很多人开发代码都没有注意到的地方,反正功能也能用,至于放哪无所谓呗。这样往往造成后面代码无法复用,层级关系混乱,对后续代码的维护非常麻烦。

  阿里巴巴规约中的分层比较清晰简单明了,但是描述得还是过于简单了,以及Service层和Manager层有很多同学还是有点分不清楚之间的关系,就导致了很多项目中根本没有Manager层的存在。下面介绍一下具体业务中应该如何实现分层。

  是我们阿里分层规范里面的第一层:轻业务逻辑,参数校验,异常兜底。通常这种接口可以轻易更换接口类型,所以业务逻辑必须要轻,甚至不做具体逻辑。

  层去做的话,如果以后我们要接入其他框架,我们这里又需要把业务编排在做一次,这样会导致我们每接入一个入口层这个代码都得重新复制一份如下图所示:

  这样大量的重复工作必定会导致我们开发效率下降,所以我们需要把业务编排逻辑都得放进Service中去做:

  每一个层基本都自己对应的领域模型,这样就导致了有些人过于追求每一层都是用自己的领域模型,这样就导致了一个对象可能会出现3次甚至4次转换在一次请求中,当返回的时候同样也会出现3-4次转换,这样有可能一次完整的请求-返回会出现很多次对象转换。如果在开发中真的按照这么来,恐怕就别写其他的了,一天就光写这个重复无用的逻辑算了吧。

  根据很多Java程序员的”经验”来看,一个数据库表则对应着一个Domain对象,所以很多程序员在写代码时,包名则使用:com.xxx.domain,这样写好像已经成为了行业的一种约束,数据库映射对象就应该是domain。但是你错了,domain是一个领域对象,往往我们再做传统Java软件Web开发中,这些domain都是贫血模型,是没有行为的,或是没有足够的领域模型的行为的,所以,以这个理论来讲,这些domain都应该是一个普通的entity对象,并非领域对象,所以请把包名改为:com.xxx.entity。


点击次数:  更新时间:2020-10-06 20:38   【打印此页】  【关闭
http://gentecilla.com/fencengbianma/131/