代码分层，关于任何一个Java Web开发来说应该都不生疏。一个好的层次差异不只能够能使代码结构愈加清楚，还能够使项目分工愈加清晰，可读性大大提高，愈加有利于后期的保护和晋级。
从别的一个视点来看，好的代码分层架构，应该是能够很好的匹配上单一责任准则的。这样就能够降低层与层之间的依靠，还能最大程度的复用各层的逻辑。本文就来介绍下Java Web项意图代码究竟应该怎么分层。
三层架构
在软件体系架构规划中，分层式结构是最常见，也是最重要的一种结构。微软引荐的分层式结构一般分为三层，从下至上分别为：数据拜访层、业务逻辑层（又或称为范畴层）、表明层。这也是Java Web中重要的三层架构中的三个层次。差异层次的意图即为了“高内聚低耦合”的思维。
所谓三层体系结构，是在客户端与数据库之间加入了一个“中间层”，也叫组件层。这儿所说的三层体系，不是指物理上的三层，不是简略地放置三台机器便是三层体系结构，也不只仅有B/S使用才是三层体系结构，三层是指逻辑上的三层，即把这三个层放置到一台机器上。
数据拜访层
首要是对非原始数据（数据库或许文本文件等寄存数据的办法）的操作层，而不是指原始数据，也便是说，是对数据库的操作，而不是数据，具体为业务逻辑层或表明层供给数据服务。
业务逻辑层
首要是针对具体的问题的操作，也能够了解成对数据层的操作，对数据业务逻辑处理，假如说数据层是积木，那逻辑层便是对这些积木的建立。
界面层
首要表明WEB办法。假如逻辑层适当强大和完善，不管体现层怎么界说和更改，逻辑层都能完善地供给服务。
三层架构与MVC的差异
MVC（模型Model-视图View-操控器Controller）是一种架构形式，能够用它来创建在域目标和UI表明层目标之间的差异。
同样是架构等级的，相同的当地在于他们都有一个体现层，可是他们不同的当地在于其他的两个层。
在三层架构中没有界说Controller的概念。这是最不同的当地。而MVC也没有把业务的逻辑拜访当作两个层，这是选用三层架构或MVC建立程序最首要的差异。
分层的最佳实践
跟着网站的用户量的不断提高，体系架构也在不断的调整。有时分，跟着业务越来越杂乱，有时分三层架构如同不行用了。比方，咱们的使用除了要给用户供给页面拜访以外，还需求供给一些敞开接口，供外部体系调用。这个接口既不归于界面层，也不该该归于业务逻辑层，由于他还或许包含一些和业务逻辑无关的处理，如权限操控、流量操控等。
还有，跟着微服务的盛行，咱们使用中或许要依靠许多外部接口或第三方渠道。这部分代码放下业务逻辑层和数据拜访层也都不适宜。
所以，逐渐的，在三层架构的根底上，体系架构的分层变得愈加杂乱了。也正是由于杂乱，就十分检测架构规划才能，由于层次差异的欠好，很或许会影响后边的开发，给代码保护带来很大的困难。
下图，是阿里巴巴（参阅《阿里巴巴Java开发手册》）发起的使用分层结构：
敞开接口层
可直接封装 Service 办法露出成 RPC 接口；经过 Web 封装成 http 接口；进行网关安全操控、流量操控等。
终端显现层
各个端的模板烘托并履行显现的层。当时首要是 velocity 烘托，JS 烘托，JSP 烘托，移动端展现等。
Web 层
首要是对拜访操控进行转发，各类基本参数校验，或许不复用的业务简略处理等。
Service 层
相对具体的业务逻辑服务层。
Manager 层
通用业务处理层，它有如下特征： 1） 对第三方渠道封装的层，预处理回来成果及转化反常信息； 2） 对 Service 层通用才能的下沉，如缓存计划、中间件通用处理； 3） 与 DAO 层交互，对多个 DAO 的组合复用。
DAO 层
数据拜访层，与底层 MySQL、Oracle、Hbase 等进行数据交互。
外部接口或第三方渠道
包含其它部分 RPC 敞开接口，根底渠道，其它公司的 HTTP 接口。
业务处理
在了解了分层之后，咱们再来看一下写Java Web代码的时分，我们比较关心的一个问题，那便是涉及到数据库操作的时分，业务处理应该在哪一层操控呢？
关于这个问题，仁者见仁，智者见智。作者以为，业务处理应该放在Service层和Manager层。
DAO层不该该有业务，应该仅仅很纯的 CRUD 等比较通用的数据拜访办法。一个DAO应该只处理和自己相关的操作，不要有任何组合。组合的工作交给上层。
Service层和Manager层一般会组合多个DAO的CRUD操作，例如：在注册一个用户的时分需求往日志表里 INSERT 日志，那么就在 Service 层结构业务，在该业务中调用 Dao 层的 User.Insert （） 与 Log.Insert （）。
反常处理
反常处理是Java中比较重要的一个论题，在《EffecTIve Java》中有许多关于反常处理的最佳实践，这儿不具体介绍了，本文首要简略说一下在使用代码分层之后，各个层次之间的反常应该怎么处理，是自己捕获，仍是向上一层抛出。
首要，每一层都是或许产生反常的。由于每一层的责任都不通，处理办法也或许有不同。
DAO层
在 DAO 层，产生的反常类型或许有许多，或许是SQL相关的反常，也或许是数据库衔接相关的反常。
这一层的处理办法能够简略一点，直接try-catch（ExcepTIon），然后封装成DAOExcepTIon抛给上一层。这一层一般不需求打印日志，交给Service或许Manager层来打印。
try{ CRUD }catch（ExcepTIon e）{ throw new DAOException（e）; }
Manager/Service
首要，关于DAO层抛上来的反常一定要捕获的，而且记载日志打印现场。
可是值得注意的是，假如是需求业务操控的办法，要注意捕获到反常之后再向上抛一个新的反常，如 TransactionRolledbackException，不然业务无法回滚。
这两层产生的反常能够依据状况决定是持续向上抛仍是自己处理掉。假如是自己能够处理的反常，就捕获，打日志，然后经过ErrorCode等办法回来给上一层。假如是自己无法处理或许不知道该怎么处理的反常，就直接抛给上一层来处理。
Web
首要，能够清晰的一点：Web层不该该再往外抛反常，由于这一层一旦抛反常，就或许会导致用户跳转到不友爱的过错页面乃至看到过错信息等。
假如意识到这个反常将导致页面无法正常烘托，那么就应该直接跳转到友爱过错页面，加上用户简略了解的过错提示信息。
敞开接口层
这一层和Web层相同，不能够抛出反常。一般经过ErrorCode和ErrorMessage反馈给外部调用方。
这一层，要自己处理好一切的反常，界说好ErrorCode，并记载好日志，便于日后排查问题。
总结
本文首要介绍了Java Web项目中代码分层的计划，经过分层之后能够使没一层愈加专心，免除耦合。并简略介绍了一下分层之后的业务处理和反常处理的逻辑。
