데이터베이스 운영 계층 구조 요약

영구화된 데이터의 읽기와 쓰기 작업에서 데이터베이스와 캐시 작업이 자주 관련되고 업무상 다중 테이블에 대한 업무 작업이 필요하기 때문이다.구조적 차원화 디자인의 사상을 바탕으로 우리는 종종 이 일련의 조작에 대해 층별 설계를 해야 한다.
각 층의 주요 직책, 그리고 이상이 발생하면 어떻게 처리하는지, 위로 계속 던지는지, 아니면 이 층에서 이상을 전환하는 등 처리하는지, 업무 중에 이상이 발생할 때 캐시 처리하는 등 고민이 필요하다.
개인의 경험을 예로 들면 지구화 조작을 흔히 3층으로 나눈다. 그것이 바로dao층, 관리자층, 서비스층이다. 그 중에서dao층: 데이터베이스 읽기와 쓰기 조작을 직접 한다.이상이 발생했을 때 위로 던지면 호출자는 포획된 이상 정보에 따라db방생 오류의 원인을 찾을 수 있다(sql 문법 오류나 같은 키를 중복 삽입하는 등)
public List<Something> queryList(SomethingQuery SomethingQuery) throws DAOException;

관리자 층: 캐시와 함께 데이터베이스에 대한 읽기와 쓰기를 바꾸는 것입니다.내 방식
insert:
     insertDB(something)    //    db
query:
     something = getSomethingFromCache   //     ,     db
     if(something == NULL) {
         something = getSomethingFromDB
         putSomethingToDB(something)
     }
     return something
update:
    updateDB(something)    //  db,           
    invalidCache(something)
delete:
     deleteDB(something)   //  db   ,           
     invalidCache(something)

이 층에 이상이 발생했을 때 대외적으로 투매하여 처리하지 않았다.이전의 방법은 이 층에서 이상을 많이 처리했다. 만약에 이상이 발생하면 나는null로 되돌아간다. 이런 폐단은 호출자가null에 대해 진일보한 구분을 할 수 없다는 데 있다. (이상이 발생하든db와 캐시에 모두 존재하지 않아서 null로 되돌아오든) 그래서 오류 성능이 떨어진다. 예를 들어 이상이 발생하면 여러 번 시도할 수 있고 데이터가 존재하지 않을 때 즉시 처리로 되돌아와야 한다.아무래도 관리자층은 상대적으로 등급이 낮기 때문에 상부 호출자에게 가능한 한 많은 정보를 제공해야 하며 용착 등 착오를 쉽게 할 수 있다.
서비스 층: 이 층에서는 종종 업무의 수요에 따라 여러 표의 업무 조작을 한다.
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 = “   ”;

좋은 웹페이지 즐겨찾기