数据库操作分层结构总结

在持久化数据的读写操作中常常要涉及到 数据库与缓存 的操作，同时由于业务需要常常要对多表进行事务操作。基于结构层次化设计的思想我们常常需要对这一系列操作进行分层设计。

各层的主要职责，以及发生异常如何处理，是向上继续抛出，还是在该层对异常做转换等处理，以及事务中发生异常时缓存的处理等需要一些思考。

以个人的经验为例：
常常将持久化操作分为3层：dao层，manager层，service层
其中
dao层：直接进行数据库读写操作。
发生异常时，向上抛，调用方可以根据捕获的异常信息，找到db放生错误的原因（sql语法错误 还是 重复插入同一主键等）

public List<Something> queryList(SomethingQuery SomethingQuery) throws DAOException;

manager层：改成将配合缓存进行数据库的读写操作。
我的做法

insert:     insertDB(something)    //直接操作dbquery:     something ＝ getSomethingFromCache   //首先读缓存，不存在时读db     if(something == NULL) {         something = getSomethingFromDB         putSomethingToDB(something)     }     return somethingupdate:    updateDB(something)    //更新db，同时失效缓存中 脏数据    invalidCache(something)delete:     deleteDB(something)   //删除db中数据，同时失效缓存中 脏数据     invalidCache(something)

该层发生异常时，对外抛出，不曾不作处理。我之前的做法，在该层多异常作处理，如发生异常时 我就返回null, 这样的弊端在于 调用方对null无法做进一步的区分（是发生异常 还是 db与缓存中 均不存在 导致返回null）,从而使容错性能下降，例如如果能是异常导致的，则可以进行多次尝试，而当数据不存在时，就需要立即返回作处理了。毕竟manager层相对来说层级较低，说要向上层调用方提供尽可能多的信息，方便做容错等错里。

service层：在该层常常会根据业务的需要做多表的事务操作。

update：            doInTransaction(TransactionStatus status) {                try {                    Long tableId1 = table1.insert(something1);                    Long tableId2 = table2.insert(something2);                } catch (Exception e) {                    status.setRollbackOnly();                }            }

该层发生异常时，常常会根据业务需求作转换，例如对于查询失败操作，可以将失败的具体信息一并返回调用方，便于问题排查。

queryResult.isSuccess = false;queryResult.msg = “db error”;queryResult.msg = “不存在”;