한 4일간 무섭게 몰아치던 감기가 이제 좀 나은 것 같습니다.
늦감기 정말 무섭네요.. 건강 조심하세요~
저번 포스트에서.. 소계와 합계를 구했고..
그리고 화면에 뿌리기 좋게~ 정렬까지 되어있는 ArrayList를 만들었습니다.
저도 실제로 이런식으로 (물론 소트기능이라던가 좀 더 많은 기능을 개발한 상태로..) 플젝에서 만들어 사용하고 있습니다.
이렇게 사용해놓고 보니.. 일단 처음에는
"쿼리 작성 시간 단축"
"View에서 테이블을 그리기 위해 과도한 if else의 사용을 하기 싫다. 나중에 컬럼하나 추가되거나 하면.. 유지보수 하는 사람은.."
"이걸 하나 만들어 놓으면 비슷한 표를 그려야 하는 사람도 사용 할 수 있을 것 같다."
그리고 포스트에는 적지 않았지만
쿼리 결과의 ROW가 표에서의 Column 으로 올라가는 Pivot된 형태의 표를 쉽게 그리게 하고 싶다.
"View에서 테이블을 그리기 위해 과도한 if else의 사용을 하기 싫다. 나중에 컬럼하나 추가되거나 하면.. 유지보수 하는 사람은.."
"이걸 하나 만들어 놓으면 비슷한 표를 그려야 하는 사람도 사용 할 수 있을 것 같다."
그리고 포스트에는 적지 않았지만
쿼리 결과의 ROW가 표에서의 Column 으로 올라가는 Pivot된 형태의 표를 쉽게 그리게 하고 싶다.
라는 정도의 생각을 가지고 만들었던 이것이..
다른쪽에서도 좀 편하게 사용되기 시작했습니다.
일단, 표를 그리기 위해 주문액,클릭수,이익액등을 쿼리에서 결과로 가져왔습니다.
조건으로 기간을 주면 그 기간동안의 총 주문액. 총 클릭수등이 카테고리별로 나오게 되죠..
그런데 보여주고 싶은 것 중에서 각 데이터들간의 계산으로써 구해지는 것들이 있었습니다.
클릭수대비 주문액이라던가, 주문액 대비 이익액등 어떠한 비율을 나타내는 항목들이었습니다.
이런 것들을 예전 같았으면 쿼리에 구하는 SELECT 절을 추가해서 계산을 했을 것입니다.
그런데 일단 소계와 합계를 어플리케이션에서 Domain 객체를 직접 핸들링해서 구하게 되니까..
굳이 쿼리를 고치지 않아도 되더라구요..
일단, 필요한 값은 이미 Domain 객체가 가지고 있으니까
위의 추가로 필요한 데이터들은 그냥 그것을 가지고 계산을 하면 되었습니다.
일단, 계산에 필요한 필드 값을 getter를 이용해서 가져와서 0 처리를 해주고 계산을 합니다.
자릿수라던가, 반올림 정책등도 필드별로 간편하게 처리 할 수 있습니다.
외부 setter가 필요하지 않기 때문에 일단, getter만 정의 했구요
getter 메서드를 호출해서 필요한 값을 가져오는 이유는.. 저 같은 경우 다른 필드를 계산 할 때
만약 주문액대비이익액 이 필요하다고 할 경우 getter를 이용해야만 필요한 값을 계산해서 가져 올 수 있기 때문에
그렇게 계산했습니다.
null처리를 해주면 불필요한 연산도 막을 수 있을 것입니다.
소계와 합계의 경우에도 그 자체가 모든 카테고리의 총주문합과 이익액으로 계산하면 되는 것이기 때문에
저 상태로 적용을 해도 정확한 값을 얻을 수 있었습니다.
이렇게 적용을 하고나니.. 평균 값을 구해야 한다고 하더라구요..
조건으로 기간을 줄 경우 그 기간으로 평균을 구해야 한다는 것이었습니다.
쿼리로 계산을 하던 상태였으면
평균을 구하는 쿼리를 추가로 만들어서
평균이냐 누적이냐에 따라서 쿼리를 다르게 호출해야 했을 거에요..
어차피 이런 상태로 만들었으니 그것도 한번 이렇게 해보자 라는 생각이 있었죠.
그래서 일단 조건으로 들어온 YYYYMMDD 형식의 두 날짜 사이의 차를 구하는 메서드를 구현하고 이것으로 일단
평균값을 구하기 위한 분모를 구할 수 있도록 하였습니다.
그리고, Domain 클래스에 필드를 추가했습니다.
현재 보여줘야 할 값이 평균이냐 아니냐를 정하는 isAverage 필드와
평균을 구할 때 분모가 될 averageDivisor 입니다.
페이지의 조회 요청이 들어올 때 현재 요청이 평균인지 누적인지 체크해서
이것을 앞에서 만든 StatusTable에 넘겨주면, 그 Table에서 자기가 만든 resultDomainList에
이 값들을 setting 해주는 방법을 사용했습니다.
loop를 도는 것이 좀 낭비 같아 보이긴 했는데
이것을 다른 방법으로 되돌리기에는 시간이 좀 많이 지나버려서...ㅎㅎ
아무튼 그렇게 셋팅을 해주면 도메인 클래스에서는 아래와 같이
값을 return하게 됩니다.
슬슬 도메인 클래스가 하는 일이 많아지더라구요..
필드가 많으면 좀 복잡스러워보이기도 합니다.
그런데 좀 다르게 생각해보니..
도메인 클래스가 이렇게 하지 않으면, 결국 쿼리가 많아지던가.. 어느 누군가는
비슷한 일을 해야 하지 않나.. 하는 생각도 들더라구요..
이렇게 이렇게 되었을 때의 좋은 점은
합계,소계도 자동으로 올바른 값으로 계산이 된다는 점과
앞서 필드와 필드의 계산으로 가져 올 수 있었던 주문액대비이익액등도
자동으로 그 평균값으로 계산이 된다는 것이었습니다.
거기다가 제가 만들었던 두개의 Table 클래스를 상속해서 표를 그렸던 다른 사람이 개발한 페이지에서도
쿼리를 따로 만들필요 없이 그냥 모두 필요한 값들을 쉽게 가져 올 수 있게 되더라구요..
그리고, 합계 ROW를 맨 아래로 내려달라 옮겨달라 라고 하는 요구사항에 대해서도
VIEW를 건드릴 필요 없이, Table 클래스에서 만들어낸 ResultDomainList에서 순서만 변경해주면
그러한 요구사항도 자동으로 처리가 되었습니다.
처음에는 상당히 단순한 생각 그리고 좀 편하게 View를 그리고 싶다라는 생각으로 시작한 시험 같은 것이었습니다.
일단 , 자바쪽에 많은 것을 위임을 하고 "자기가 할 일은 자기가 한다." 라는 기분으로 클래스를 설계하고
개발을 하니 이후에 많은 부분에서 이득이 있다는 것을 느낄 수 있었습니다.
사실 이러한 방법이 더 좋은지 나쁜지에 대해서 얘기하고 싶은 생각도 없고
그렇게 얘기를 할 정도로 실력이 좋지도 않습니다.
다만, 항상 플젝에 들어가서 개발을 하다보면
단지 어플리케이션단에서 하는 일이 프레임웍에서 제공되는 트랜잭션등의 제공을 제외하면
DAO에서 SELECT하고, 그것을 MAP이나 DTO에(단순 getter, setter) 담고
화면에 뿌려주고.. controller에서 서비스 호출하면 서비스에서는 파라메터등의 체크만하고 DAO 호출하고...
너무 단순한 어플리케이션단의 작업이 조금 의아하기도 했구요..
(자바의 그 수많은 API가 아깝다..라는 생각.. ㅎㅎ)
그래서 한번 조금 다른 방법으로 생각을 해보자고 한 것이
이런 모양이 되어버렸습니다.
이미 이렇게 개발을 하셔서 이런 방식의 장단점을 잘 알고 계시는 분도 분명히 존재하실거라고 생각합니다.
저는 이번에 이렇게 개발을 하면서
데이터 핸들링에 대해 꽤 많은 생각을 할 수 있게 되었구요
개인적으로는 참 도움이 되는 생각이었던 것 같습니다.
많은 고수분들께는 어린아이 같은 생각이겠지만
반대로 많은 입문자들에게는 그래도 한번 읽어보면서 생각해볼만한 내용일지도 모른다는 생각이 들어서
그냥 일기같이 내려쓴 글입니다.
혹여 이 글을 보시는 분들께서도
그냥 어떤 초급 개발자의 "이런 생각을 하는 사람도 있구나" 라는 정도로 봐주시면
좋을 것 같습니다.
