处理服务层中的Daoexception

如果我的Dao层抛出Dao特定exception,那么在我的服务层处理它们是否会引起关注? 如果是,那么我应该将exception设为通用且独立于任何层来解决它,还是有其他方法?

同样的问题适用于服务层抛出的UI层处理exception。

当我们创建分层应用程序时,总会有一个用户层和另一个使用过的层。 对于这种情况,UI层 – >使用服务层 – >使用DAO层。

现在它非常主观和开放的解释。 但目标应该是很好的脱钩程度 。 为了实现这一点,一种方法是定义generics层特定的exception,例如PersistentExceptionServiceException等。这些exception将包装实际的层特定exception。

例如,如果在数据库端存在一些错误(约束违规等),请将其包装在PersistentException中并让服务层处理(关于如何以通用方式将此传送到UI层)

现在,由于服务层和DAO层之间的集成契约的 (基于接口),DAO层可以自由地将实现更改为任何东西,只要它遵守接口契约即可 。 因此,如果您更改了抛出一些新exception的实现,那么这些新exception可以包装在PersistentException并且Service层保持不受影响

是。 为每个层创建自己的独立exception是一个好主意。

例如,如果您正在使用特定的DAO实现,则应将特定于实现的exception包装到您自己的通用exception中,并将其转发到服务层。

但是,您需要敏感地创建自己的exception层次结构,这样它不应该是应用程序开发的开销,也不应该能够维护服务层中所需的信息。 大多数情况下,具有一般exception的自定义错误代码就足够了。

这样的东西可以用来模拟特定于实现的exception并抛出到Service层。

 class AppDAOException extends Exception { public final static int _FAIL_TO_INSERT = 1; public final static int _UPDATE_FAILED = 2; public final static int _SQL_ERROR = 3; private int errorCode; public AppDAOException(int errorCode) { this.errorCode = errorCode; } public getErrorCode() { return errorCode; } } 

从DAO实施中抛出:

 try { //code here } catch (some.impl.SQLSyntaxException e) { throw new AppDAOException (AppDAOException._SQL_ERROR ); } 

关于关注泄漏:您可能不希望您的服务层担心所有exception – 例如:

 } catch(NoRowExistsException e) { return null; } finally { //release resources } 

因此,必须根据应用需求进行调用。

当您执行以下操作时,您的DAO层已经泄漏到服务层:

 userDAO.persist(user); 

作为API的一部分的exception就像操作一样应该以同样的方式考虑。

 try { userDAO.persist(user); } catch (DAOException e) { // looks fine to me } 

运行时exception或重新抛出exception时可能会发生泄漏

 try { userDAO.persist(user); } catch (SQLException e) { // sql implementation exposed } 

但即使这听起来也比“独立于层”的例外更好

好问题..!! 在UI层处理exception(例如,如果使用struts,则是actions层)是一种很好的方法。将泛例设置为generics并不是处理此问题的好方法。 然而,每一层都应该具有通用的特定例外。 例如,DAO层可能有自定义的exception处理程序,如DavaSavingException,IOException等。

因此,该方法是从DAO向服务层抛出exception,并再次将其抛出到UI层并捕获UI特定的类。

然而,根据您的应用/需求,事情太过外交。