在企业级web分层式应用中异常架构设计
2012-03-21 22:08
134 查看
做java开发已经有几年了,所面对的项目有大也有小,这些项目就整体上的设计方式无外乎就一种,那就是分层设计,一般分为dao,service,action这几层,有的项目结构为:dao,daoimpl,service,serviceimpl,action,看这些项目中都没有对异常进行很好的处理,一些项目几乎没有对异常信息进行过什么处理,而我认为,一个好的异常处理的设计对于提高开发效率是必不可少的,在项目完成后,出现问题也容易定位问题所在,下面给出我项目中采用的异常架构的处理,以部门信息为例:
dao接口,代码为:
daoimpl,代码为:
service接口,代码为:
serviceimpl,代码为:
自己包装了DepartmentDAOException,DepartmentServiceException,它们都继承自BaseException,BaseException又继承Exception,在打印异常信息时采用log4j不采用java里面的打印堆栈语句,这样做的好处是我们可以控制异常信息的打印与否,比如在给客户演示时,数据库里的数据不完整,我们并不希望客户看到这些信息,另一方面客户期望的是一个没有问题的系统,客户并不关心这些,我们可以通过这种方式不打印异常信息,只是把这些异常信息写入日志,过后我们检查日志,定位问题。
关于代码中使用的logger.serious,在log4j中并不存在,我是修改了源码,加入了一个日志级别,可以参考我的另一篇文章《为log4j增加日志级别》,下层的异常一层层向上抛,抛到action进行处理,写入日志或是通过struts进行处理等等,或许有人认为这样处理太麻烦了,麻烦是麻烦了点,不过带来的好处只在亲身体验过就知道了,当然这只是一种处理方法,不知道还是没有更好的处理办法
dao接口,代码为:
/**
* 根据传入的部门主键查找对应的部门
* @param id部门的主键
* @return Department
*/
public Department findById(Long id) throws DepartmentDAOException;
daoimpl,代码为:
/**
* 根据传入的部门主键查找对应的部门
* @param id部门的主键
* @return Department
* @throws DepartmentDAOException
*/
public Department findById(Long id) throws DepartmentDAOException {
try {
return (Department)this.getSqlMapClientTemplate().queryForObject("Department.getDepartmentById", id);
} catch (Exception e) {
logger.serious(e.getMessage(), e);
throw new DepartmentDAOException("DepartmentDAOImpl.findById","DAOException",e);
}
}
service接口,代码为:
/**
* 根据传入的部门主键查找对应的部门
* @param id部门的主键
* @throws DepartmentServiceException
* @return DepartmentVO
*/
public DepartmentVO doFindById(Long id) throws DepartmentServiceException;
serviceimpl,代码为:
/**
* 根据传入的部门主键查找对应的部门
* @param id部门的主键
* @throws DepartmentServiceException
* @return DepartmentVO
*/
public DepartmentVO doFindById(Long id) throws DepartmentServiceException {
try {
Department pojo = departmentDAO.findById(id);
DepartmentVO vo = new DepartmentVO();
BeanUtils.copyProperties(vo, pojo);
return vo;
} catch (Exception e) {
logger.serious(e.getMessage(), e);//这个日志级别是自定义的,对log4j源码进行了修改
throw new DepartmentServiceException("DepartmentServiceImpl.doFindById","ServiceException",e);
}
}
自己包装了DepartmentDAOException,DepartmentServiceException,它们都继承自BaseException,BaseException又继承Exception,在打印异常信息时采用log4j不采用java里面的打印堆栈语句,这样做的好处是我们可以控制异常信息的打印与否,比如在给客户演示时,数据库里的数据不完整,我们并不希望客户看到这些信息,另一方面客户期望的是一个没有问题的系统,客户并不关心这些,我们可以通过这种方式不打印异常信息,只是把这些异常信息写入日志,过后我们检查日志,定位问题。
关于代码中使用的logger.serious,在log4j中并不存在,我是修改了源码,加入了一个日志级别,可以参考我的另一篇文章《为log4j增加日志级别》,下层的异常一层层向上抛,抛到action进行处理,写入日志或是通过struts进行处理等等,或许有人认为这样处理太麻烦了,麻烦是麻烦了点,不过带来的好处只在亲身体验过就知道了,当然这只是一种处理方法,不知道还是没有更好的处理办法
相关文章推荐
- .NET企业级应用架构设计系列之开场白
- .NET企业级应用架构设计系列之一
- NET企业级应用架构设计系列之技术选型
- .NET应用架构设计—重新认识分层架构(现代企业级应用分层架构核心设计要素)
- [转]企业级Web应用用户界面设计杂谈
- .Net企业级应用架构设计之设计原则和模式
- Spring Cloud Spring Boot mybatis分布式微服务云架构(十一)Web应用的统一异常处理
- 企业级应用架构设计系列之技术选型
- NET企业级应用架构设计系列之技术选型
- .NET企业级应用架构设计的技术选型
- 企业级系统架构设计技术与互联网应用技术结合主题一 大规模并发性能问题探讨
- MicrosoftNet企业级应用架构设计(下)
- Spring Cloud Spring Boot mybatis分布式微服务云架构(十一)Web应用的统一异常处理
- .NET企业级应用架构设计系列
- Microsoft.NET 企业级应用架构设计-UML必要知识
- .Net企业级应用架构设计之业务层设计
- .Net企业级应用架构设计之表现层设计
- .NET企业级应用架构设计系列之技术选型
- 企业级Web应用用户界面设计杂谈
- 今日随想——关于企业级应用中分布式架构设计中系统通讯问题