쿼리안에 로직

로직이 쿼리에 들어가는 일은 보통 쿼리와 데이터 중심으로 로직을 구현할 때 많이 발생한다. 

 

이는 사용자의 요구조건을 쿼리에서 처리하는 것이며, 이는 데이터 조작과 로직이 일치하기 때문에 매우 개발이 편해진다. 

 

 

예시 코드를 살펴보자.

 

코드 1

public int updateMemberStatus(String id){
 //update 후 영향 받은 레코드의 수를 반환하는 메서드
 update member set status = 20 where member_id = ? and status = 10;
}

{
	int cnt = updateMemberStatus(id);
    //영향  받은 record의 수에 따라 분기하는 로직
    if(cnt == 0){
    	...
    }else{
    	...
    }
	
}

 

 

코드 2

public Long updateCloseStatus(Long id){
 //update 후 영향 받은 레코드의 수를 반환하는 메서드
 update account acc
 join contract ct on ct.cntr_id = sp.cntr_id
 set acc.status = 'CLOSE'
 where ct.cntr_id = ? and ct.status = 100
}

{
	int cnt = updateCloseStatus(id);
    //영향  받은 record의 수에 따라 분기하는 로직
    if(cnt == 0){
    	...
    }else{
    	...
    }
	
}

 

코드 2의 쿼리는 account Table을 Update 하지만 contract라는 테이블과 조인 후 조건절에서 id와 status값이 100이면 account 레코드를 업데이트한다.

 

쿼리를 제외하고 메서드를 통해 결괏값으로 분기하는 코드만으로 보면 비즈니스 로직이 어떤 식으로 흘러가는지 알 수 없다.

 

 

이를 통해 알 수 있는 점은 로직이 쿼리에 들어가게 되면 주요 로직이 흩어진다. 

 

초기 회사에 입사하고 진행 중인 프로젝트의 코드를 받았을 때 충격을 먹고 당황한 적이 있다. 

 

어떤 비즈니스 로직은 자바스크립트에 존재하고 어떤 건 Controller단에서 처리하고 어떤 건 DB의 SP를 통해 처리한다. 

또 이중에는 데이터베이스 트리거 혹은 패키지를 사용해 도저히 한눈에 뭐가 뭔지 알 수가 없고 현재도 문제가 발생하면 비즈니스를 이해하기 위해 코드를 따라가는데 한 세월이 걸린다. 

이는 신입들이 적응하는데 거의 불가능한 수준이고 회사의 고인물들만 아는 수준이다. 

 

또 이러한 구조에서는 미세하게 변경되어야 하는 요구조건이 오면 수많은 중복이 발생한다. 

객체지향을 공부하면서 객체지향의 객체들은 자율성을 가지고 메시지를 전달받아 각자의 책임을 수행한다. 

여기서 자율적이라는 소리는 책임을 처리하는 방법에 대한 자율성이 중요하다고 배웠다. 하지만 이러한 미세한 변경사항에 유연하게 대처하지 못하고 중복을 통해 처리하는 것은 뭔가 잘못된다는 생각이 든다. 

 

또 주요 로직을 단위 테스트하기 매우 어렵습니다.  쿼리를 실행을 해야 로직 검증이 가능하기 때문입니다.

 

 

Member member = mdao.selectById(id);

if(member = null) // 실패처리
if(member.getStatus() != 10)...

member.setStatus(20);
mdao.update(member);

 

member_id 값을 가지고 비즈니스 로직을 처리하기보단 위 코드와 같이 해당 member을 가져와서

상태를 변경하고 업데이트하는.. 이 중에서 setStatus(20)을 비즈니스 로직을 처리하는 부분이라고 생각할 수 있다.

 

Contract ct = ctDao.selectById(id);

if(ct ==null)...실패
if(!ct.isOnService())...실패

Account acc = accDao.selectByCntrId(ct.getId());

if(acc == null) // 실패처리

acc.close();
accDao.update(acc);

 

이렇게 변경되면 코드 가독성이 개선되어 보인다.  개발자가 실패하는 조건을 빠르게 파악할 수 있고 업무의 흐름을 빠르게 파악할 수 있는 코드로 보인다. 

 

또 이는 상태 변경 기능과 관련된 쿼리가 몇 가지가 되지 않도록 단순해진다. 

상태를 쿼리에서 처리하는 것이 아닌 애플리케이션단으로 끄집어내서 사용하기 때문이다.

 

 

정리

• 상태 변경과 관련된 로직을 쿼리에 넣지 말고 다만 배치와 같이 대량의 데이터를 다루는 경우는 성능 검토가 필요하다.