应用分层 🌋
- hello
- 场景示例
- 异常全局处理
幸福,不是长生不老,不是大鱼大肉,不是权倾朝野。幸福是每一个微小的生活愿望达成。当你想吃的时候有得吃,想被爱的时候有人来爱你
应用分层是一种常见的软件设计模式,将整个应用程序分解成若干个层次结构,并将每个层次结构分配特定的职责。常见的分层结构包括DAO层、Service层、Manager层、Web层和开放接口层等。
DAO层:数据访问层,负责与底层数据库进行交互;
Service层:业务逻辑服务层,负责实现具体的业务逻辑,并调用DAO层进行数据操作;
Manager层:通用业务处理层,负责协调不同的Service层,提供缓存方案、中间件通用处理等通用能力;
Web层:接收HTTP请求,进行参数校验和路由转发,调用Manager层处理业务逻辑,并将结果返回给客户端;
开放接口层:封装Service方法,暴露成RPC接口或HTTP接口,处理异常,并返回结果。
通过应用封层,我们可以将应用程序分解成多个松耦合的层次结构,使得系统的各个部分可以独立发展,更加灵活、可扩展和易维护。同时,应用封层也能提高系统的可用性和用户体验,保证系统的稳定性和安全性。
hello
开放接口层:可直接封装 Service 方法暴露成 RPC 接口;通过 Web 封装成 http 接口;进行
网关安全控制、流量控制等。
终端显示层:各个端的模板渲染并执行显示的层。当前主要是 velocity 渲染,JS 渲染,
JSP 渲染,移动端展示等。
Web 层:主要是对访问控制进行转发,各类基本参数校验,或者不复用的业务简单处理等。
Service 层:相对具体的业务逻辑服务层。
Manager 层:通用业务处理层,它有如下特征:
1) 对第三方平台封装的层,预处理返回结果及转化异常信息;
2) 对 Service 层通用能力的下沉,如缓存方案、中间件通用处理;
3) 与 DAO 层交互,对多个 DAO 的组合复用。
DAO 层:数据访问层,与底层 MySQL、Oracle、Hbase 等进行数据交互。
外部接口或第三方平台:包括其它部门 RPC 开放接口,基础平台,其它公司的 HTTP 接口。
场景示例
一个简单的场景示例,以展示各个分层如何协同工作:
假设我们正在开发一个电商网站,其中有一个订单管理模块。订单管理模块需要提供如下功能:
- 创建订单
- 取消订单
- 查询订单详情
- 查询订单列表
我们将按照分层规定,分别实现如下的代码结构:
DAO层:
public interface OrderDao {
void create(Order order);
void update(Order order);
void delete(long orderId);
Order getById(long orderId);
List<Order> getListByUserId(long userId);
}
Service层:
public interface OrderService {
void createOrder(Order order) throws ServiceException;
void cancelOrder(long orderId) throws ServiceException;
Order getOrderById(long orderId) throws ServiceException;
List<Order> getOrderListByUserId(long userId) throws ServiceException;
}
Manager层:
public interface OrderManager {
void createOrder(Order order) throws ManagerException;
void cancelOrder(long orderId) throws ManagerException;
Order getOrderById(long orderId) throws ManagerException;
List<Order> getOrderListByUserId(long userId) throws ManagerException;
}
Web层:
@RestController
@RequestMapping("/orders")
public class OrderController {
@Autowired
private OrderManager orderManager;
@PostMapping
public void createOrder(@RequestBody Order order) {
try {
orderManager.createOrder(order);
} catch (ManagerException e) {
// handle exception
}
}
@DeleteMapping("/{orderId}")
public void cancelOrder(@PathVariable("orderId") long orderId) {
try {
orderManager.cancelOrder(orderId);
} catch (ManagerException e) {
// handle exception
}
}
@GetMapping("/{orderId}")
public Order getOrderById(@PathVariable("orderId") long orderId) {
try {
return orderManager.getOrderById(orderId);
} catch (ManagerException e) {
// handle exception
return null;
}
}
@GetMapping
public List<Order> getOrderListByUserId(@RequestParam("userId") long userId) {
try {
return orderManager.getOrderListByUserId(userId);
} catch (ManagerException e) {
// handle exception
return null;
}
}
}
开放接口层:
public interface OrderRpcService {
Order createOrder(Order order) throws RpcException;
void cancelOrder(long orderId) throws RpcException;
Order getOrderById(long orderId) throws RpcException;
List<Order> getOrderListByUserId(long userId) throws RpcException;
}
以上是一个简单的示例,其中各个分层的职责如下:
- DAO层:负责与底层数据库交互,提供基本的CRUD操作;
- Service层:负责实现具体的业务逻辑,调用DAO层进行数据操作,并处理异常;
- Manager层:负责协调不同的Service层,处理多个DAO的组合复用,提供缓存方案、中间件通用处理等通用能力;
- Web层:负责接收HTTP请求,并进行参数校验和路由转发,调用Manager层处理业务逻辑,处理异常,并将结果返回给客户端;
- 开放接口层:负责将Service层封装成RPC接口,暴露给其他部门或者第三方平台调用,处理异常,并返回结果。
现在,我们可以通过如下方式将各个分层串联起来,完成电商网站订单管理模块的实现:
- 客户端发送HTTP请求到Web层的接口;
- Web层的接口进行参数校验和路由转发,将请求转发给OrderController中对应的方法;
- OrderController中的方法调用OrderManager的对应方法,处理业务逻辑,并抛出ManagerException异常;除非有全局异常处理
- OrderManager对异常进行捕获和处理,并将异常封装为ManagerException异常抛出;
- OrderService对异常进行捕获和处理,并将异常封装为RpcException异常抛出;
- 开放接口层的OrderRpcService对异常进行捕获和处理,并将异常封装为特定的错误码和错误信息,返回给客户端。
通过以上的分层结构,我们可以将电商网站订单管理模块进行灵活的组合和扩展,实现高性能、高可靠的订单管理服务。同时,各个分层职责明确,耦合度低,便于测试和维护。
其实Manager层组合Service也罢, 组合Dao层也好, 都是起到一个组合的中间层
异常全局处理
如果Controller中抛出ManagerException异常,客户端无法理解这个异常的含义,所以需要对异常进行全局处理。常见的做法是在Web层中增加一个异常处理器,将所有的异常统一处理,并返回友好的错误信息。
例如,我们可以定义一个全局异常处理器类,如下所示:
@ControllerAdvice
public class GlobalExceptionHandler {
@ExceptionHandler(Exception.class)
@ResponseBody
public ResponseEntity<ErrorResponse> handleException(Exception e) {
ErrorResponse errorResponse = new ErrorResponse();
errorResponse.setCode(HttpStatus.INTERNAL_SERVER_ERROR.value());
errorResponse.setMessage("系统繁忙,请稍后再试");
if (e instanceof ManagerException) {
// 如果是ManagerException异常,将异常信息封装到ErrorResponse中
ManagerException managerException = (ManagerException) e;
errorResponse.setCode(managerException.getCode());
errorResponse.setMessage(managerException.getMessage());
} else if (e instanceof ServiceException) {
// 如果是ServiceException异常,将异常信息封装到ErrorResponse中
ServiceException serviceException = (ServiceException) e;
errorResponse.setCode(serviceException.getCode());
errorResponse.setMessage(serviceException.getMessage());
} else if (e instanceof RpcException) {
// 如果是RpcException异常,将异常信息封装到ErrorResponse中
RpcException rpcException = (RpcException) e;
errorResponse.setCode(rpcException.getCode());
errorResponse.setMessage(rpcException.getMessage());
}
return ResponseEntity.status(HttpStatus.INTERNAL_SERVER_ERROR).body(errorResponse);
}
}
在这个异常处理器中,我们首先判断异常的类型,如果是ManagerException、ServiceException或RpcException异常,则将异常信息封装到一个ErrorResponse对象中,并返回给客户端。如果是其他类型的异常,则将默认的错误信息封装到ErrorResponse中,并返回给客户端。
通过这种方式,我们可以对异常进行全局处理,将异常信息封装成友好的错误信息返回给客户端,提高系统的可用性和用户体验。